re: how to tell if a process is 64-bit

Thor Lancelot Simon writes: > On Sun, Sep 10, 2017 at 03:29:22PM +, paul.kon...@dell.com wrote: > > > > MIPS has four ABIs, if you include "O64". Whether a particular OS allows > > all four concurrently is another matter; it isn't clear that would make > > sense. Mixing "O" and "N" ABIs is

Re: how to tell if a process is 64-bit

On Sun, Sep 10, 2017 at 03:29:22PM +, paul.kon...@dell.com wrote: > > MIPS has four ABIs, if you include "O64". Whether a particular OS allows > all four concurrently is another matter; it isn't clear that would make > sense. Mixing "O" and "N" ABIs is rather messy. > > Would you call N32

Re: Proposal: Disable autoload of compat_xyz modules

On Sun, Sep 10, 2017 at 09:03:27PM +0200, Maxime Villard wrote: > If you have a fix to untangle this mess, be my guest. I proposed to > reimplement > the 43* functions separately into compat_linux, people disagreed. Others have proposed to move it to a compat_common module, and this is the way

Re: Proposal: Disable autoload of compat_xyz modules

Le 10/09/2017 à 20:51, Manuel Bouyer a écrit : On Sun, Sep 10, 2017 at 08:46:52PM +0200, Maxime Villard wrote: Le 10/09/2017 à 19:59, Manuel Bouyer a écrit : There's something I don't understand in this thread: what is the point of having the code in kernel if you still have to use modload to

Re: Proposal: Disable autoload of compat_xyz modules

On Sun, Sep 10, 2017 at 08:46:52PM +0200, Maxime Villard wrote: > Le 10/09/2017 à 19:59, Manuel Bouyer a écrit : > > There's something I don't understand in this thread: what is the point > > of having the code in kernel if you still have to use modload to make it > > availble ? Why not comment it

Re: Proposal: Disable autoload of compat_xyz modules

Le 10/09/2017 à 19:59, Manuel Bouyer a écrit : There's something I don't understand in this thread: what is the point of having the code in kernel if you still have to use modload to make it availble ? Why not comment it out in kernel and have users modload it if they want to ? said earlier,

Re: performance issues during build.sh -j 40 kernel

On Sun, Sep 10, 2017 at 07:56:11PM +0200, Maxime Villard wrote: > Le 10/09/2017 à 19:50, Joerg Sonnenberger a écrit : > > On Sun, Sep 10, 2017 at 07:17:51PM +0200, Joerg Sonnenberger wrote: > > > That's true, but changing this also has quite a significant downside on > > > some workloads for

Re: Proposal: Disable autoload of compat_xyz modules

There's something I don't understand in this thread: what is the point of having the code in kernel if you still have to use modload to make it availble ? Why not comment it out in kernel and have users modload it if they want to ? -- Manuel Bouyer NetBSD: 26 ans

Re: performance issues during build.sh -j 40 kernel

Le 10/09/2017 à 19:50, Joerg Sonnenberger a écrit : On Sun, Sep 10, 2017 at 07:17:51PM +0200, Joerg Sonnenberger wrote: That's true, but changing this also has quite a significant downside on some workloads for second order effects. I don't think it is a good idea to change this right now, as

Re: performance issues during build.sh -j 40 kernel

Mateusz Guzik wrote: > ... > > 1) #define UBC_NWINS 1024 > > The parameter was set in 2001 and is used on amd64 to this very day. > > lockstat says: > 51.63 585505 321201.06 e4011d8304c0 > 40.39 291550 251302.17 e4011d8304c0 ubc_alloc+69 > 9.13

Re: Proposal: Disable autoload of compat_xyz modules

Le 10/09/2017 à 17:24, Greg Troxel a écrit : [...] Reading maxv@'s suggestion, I wondered about autoload of non-built-in modules (but maybe that is already disabled). My quick reaction is that it would be nice if the "don't autoload" flag had the same behavior for builtin and non-builtin

Re: performance issues during build.sh -j 40 kernel

On Sun, Sep 10, 2017 at 07:17:51PM +0200, Joerg Sonnenberger wrote: > That's true, but changing this also has quite a significant downside on > some workloads for second order effects. I don't think it is a good idea > to change this right now, as it doesn't even fix the real problem. Just to

Re: performance issues during build.sh -j 40 kernel

Thanks for this analysis. I have three remarks: Le 09/09/2017 à 20:48, Mateusz Guzik a écrit : [...] I installed the 7.1 release, downloaded recent git snapshot and built the trunk kernel while using config stolen from the release (had to edit out something about 3g modems to make it compile).

Re: performance issues during build.sh -j 40 kernel

On Sat, Sep 09, 2017 at 08:48:19PM +0200, Mateusz Guzik wrote: > 1) #define UBC_NWINS 1024 Yes, this one should scale automatically. Needs a bit thought about that a good scaling would be. > 2. uvm_pageidlezero I disagree on this, a lot. At best it is a band aid unless the uvm_f?pageqlock

Re: how to tell if a process is 64-bit

> On Sep 10, 2017, at 10:31 AM, Thor Lancelot Simon wrote: > > On Fri, Sep 08, 2017 at 07:38:24AM -0400, Mouse wrote: >>> In a cross-platform process utility tool the question came up how to >>> decide if a process is 64-bit. >> >> First, I have to ask: what does it mean to say

Re: Proposal: Disable autoload of compat_xyz modules

> Am 10.09.2017 um 12:35 schrieb Maxime Villard : > > Le 10/09/2017 à 12:24, Paul Goyette a écrit : >> On Sun, 10 Sep 2017, Maxime Villard wrote: >>> Re-thinking about this again, it seems to me we could simply add a flags >>> field in modinfo_t, with a bit that says "if this

performance issues during build.sh -j 40 kernel

Hello, I have been playing a little bit with a NetBSD vm running on Centos7 + kvm. I ran into severe performance issues which I partially investigated. A bunch of total hacks was written to confirm few problems, but there is nothing committable without doing actual work and major problems remain.

Re: Proposal: Disable autoload of compat_xyz modules

Manuel Bouyer writes: > On Sun, Sep 10, 2017 at 12:17:58PM +0200, Maxime Villard wrote: >> Re-thinking about this again, it seems to me we could simply add a flags >> field in modinfo_t, with a bit that says "if this module is builtin, then >> don't load it". To use

Re: how to tell if a process is 64-bit

On 10.09.2017 16:31, Thor Lancelot Simon wrote: > On Fri, Sep 08, 2017 at 07:38:24AM -0400, Mouse wrote: >>> In a cross-platform process utility tool the question came up how to >>> decide if a process is 64-bit. >> >> First, I have to ask: what does it mean to say that a particular >> process is

Re: how to tell if a process is 64-bit

On Fri, Sep 08, 2017 at 07:38:24AM -0400, Mouse wrote: > > In a cross-platform process utility tool the question came up how to > > decide if a process is 64-bit. > > First, I have to ask: what does it mean to say that a particular > process is - or isn't - 64-bit? I think the only simple answer

Re: Proposal: Disable autoload of compat_xyz modules

Le 10/09/2017 à 13:37, Manuel Bouyer a écrit : On Sun, Sep 10, 2017 at 01:32:27PM +0200, Maxime Villard wrote: Le 10/09/2017 à 13:16, Manuel Bouyer a écrit : On Sun, Sep 10, 2017 at 01:13:14PM +0200, Maxime Villard wrote: True enough; but in this particular case, leaving compat features

Re: Proposal: Disable autoload of compat_xyz modules

On Sun, Sep 10, 2017 at 01:32:27PM +0200, Maxime Villard wrote: > Le 10/09/2017 à 13:16, Manuel Bouyer a écrit : > > On Sun, Sep 10, 2017 at 01:13:14PM +0200, Maxime Villard wrote: > > > True enough; but in this particular case, leaving compat features enabled > > > just > > > for the sake of

Re: Proposal: Disable autoload of compat_xyz modules

On Sun, Sep 10, 2017 at 01:13:14PM +0200, Maxime Villard wrote: > True enough; but in this particular case, leaving compat features enabled just > for the sake of simplicity produces a system that is much more vulnerable than > if it had one level of indirection. If you know it's vulnerable then

Re: Proposal: Disable autoload of compat_xyz modules

Le 10/09/2017 à 12:22, Manuel Bouyer a écrit : On Sun, Sep 10, 2017 at 12:17:58PM +0200, Maxime Villard wrote: Re-thinking about this again, it seems to me we could simply add a flags field in modinfo_t, with a bit that says "if this module is builtin, then don't load it". To use compat_xyz,

Re: Proposal: Disable autoload of compat_xyz modules

On Sun, Sep 10, 2017 at 12:38:52PM +0200, Maxime Villard wrote: > Le 10/09/2017 à 12:22, Manuel Bouyer a écrit : > > On Sun, Sep 10, 2017 at 12:17:58PM +0200, Maxime Villard wrote: > > > Re-thinking about this again, it seems to me we could simply add a flags > > > field in modinfo_t, with a bit

Re: Proposal: Disable autoload of compat_xyz modules

Le 10/09/2017 à 12:24, Paul Goyette a écrit : On Sun, 10 Sep 2017, Maxime Villard wrote: Re-thinking about this again, it seems to me we could simply add a flags field in modinfo_t, with a bit that says "if this module is builtin, then don't load it". To use compat_xyz, you'll have to type

Re: Proposal: Disable autoload of compat_xyz modules

On Sun, 10 Sep 2017, Maxime Villard wrote: Re-thinking about this again, it seems to me we could simply add a flags field in modinfo_t, with a bit that says "if this module is builtin, then don't load it". To use compat_xyz, you'll have to type modload, and the kernel will load the module from

Re: Proposal: Disable autoload of compat_xyz modules

On Sun, Sep 10, 2017 at 12:17:58PM +0200, Maxime Villard wrote: > Re-thinking about this again, it seems to me we could simply add a flags > field in modinfo_t, with a bit that says "if this module is builtin, then > don't load it". To use compat_xyz, you'll have to type modload, and the > kernel

Re: Proposal: Disable autoload of compat_xyz modules

Re-thinking about this again, it seems to me we could simply add a flags field in modinfo_t, with a bit that says "if this module is builtin, then don't load it". To use compat_xyz, you'll have to type modload, and the kernel will load the module from the builtin list. Something like [1] (from