On Sun, Sep 10, 2017 at 06:51:31PM +0100, Mindaugas Rasiukevicius wrote:
> Mateusz Guzik wrote:
> > 1. exclusive vnode locking (genfs_lock)
> >
> > ...
> >
> > 2. uvm_fault_internal
> >
> > ...
> >
> > 4. vm locks in general
> >
>
> We know these points of lock contention, but they are not really
> Le 09/09/2017 à 20:48, Mateusz Guzik a écrit :
On Sun, Sep 10, 2017 at 07:29:11PM +0200, Maxime Villard wrote:
> 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 t
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 r
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 a
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 to
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 m
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
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, bu
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 second
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 d'experience feront toujour
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 it
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 255967 56776.26 e
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 modules
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 quan
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). I
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 handli
> 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 that a particula
> 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 module is builtin, t
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.
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 compat_xyz, you'll have to ty
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 -
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
Le 10/09/2017 à 12:43, Manuel Bouyer a écrit :
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
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 enable
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 simp
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 simplicity produces a system that is much more vulnerable than
if it had one level of indi
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 f
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, you
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 th
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 modl
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 t
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 w
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 me
33 matches
Mail list logo