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

[Joerg Sonnenberger <joerg%bec.de@localhost>]

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 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 quantify this part, for a current release build on tmpfs, I see:
> > 
> > After:
> > 4267
> > 4280
> > 4261
> > 4247
> > 4300
> > 
> > Before:
> > 3915
> > 3951
> > 3991
> > 3961
> > 3968
> 
> That's the cacheline alignment on the uvm locks, right? In that case, what do
> you think are the "second order effects"?

Yes, it is adding the alignment in uvm_init.c. So an isolated build of
GENERIC on tmpfs gives:

https://www.netbsd.org/~joerg/lockstat-generic.txt

(that's without DIAGNOSTICS, hannken added a very heavy assert in genfs
recently, that needs to be investigated separateply). What I strongly
suspect is that the major factor for the lock contention in
uvm_fault_internal is still the uvm_fpageqlock contention. While a
change to the contention of that might be locally positive, it can just
as well increase the contention on the vmobjlock.

Joerg