lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Thu, 13 Apr 2017 19:04:34 +0200
From:   Peter Zijlstra <peterz@...radead.org>
To:     "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
Cc:     linux-kernel@...r.kernel.org, mingo@...nel.org,
        jiangshanlai@...il.com, dipankar@...ibm.com,
        akpm@...ux-foundation.org, mathieu.desnoyers@...icios.com,
        josh@...htriplett.org, tglx@...utronix.de, rostedt@...dmis.org,
        dhowells@...hat.com, edumazet@...gle.com, fweisbec@...il.com,
        oleg@...hat.com, bobby.prani@...il.com
Subject: Re: [PATCH tip/core/rcu 04/13] rcu: Make RCU_FANOUT_LEAF help text
 more explicit about skew_tick

On Thu, Apr 13, 2017 at 09:55:16AM -0700, Paul E. McKenney wrote:
> > > To avoid people tuning huge machines having to wait for me to give
> > > them an answer as to why they are suffering lock contention after
> > > cranking up the value of RCU_FANOUT_LEAF.

So is there a good reason to increase FANOUT_LEAF ?

> > > Or am I missing your point?
> > 
> > Your answer should be: don't do that then. Not provide them a shady work
> > around.
> > 
> > tick skew isn't pretty and has other problems (there's a reason its not
> > on by default). You're then doing two things you shouldn't.
> 
> The tick skew problem that I know of is energy efficiency for light
> workloads.  This doesn't normally apply to the large heavily loaded
> systems on which people skew ticks.
> 
> So what are the other problems?

If the jiffy updater bounces between CPUs (as is not uncommon) the
duration of the jiffy becomes an average (I think we fixed it where it
could go too fast by always jumping to a CPU which has a short jiffy,
but I'm not sure).

This further complicates some of the jiffy based loops (which arguably
should go away anyway).

And I have vague memories of it actually causing lock contention, but
I've forgotten how that worked.

Powered by blists - more mailing lists