linux-kernel - Re: Severe performance regression w/ 4.4+ on Android due to cgroup locking changes

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 linux-cve-announce 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]

Message-ID: <20160714112046.GB15005@htj.duckdns.org>
Date:	Thu, 14 Jul 2016 07:20:46 -0400
From:	Tejun Heo <tj@...nel.org>
To:	Peter Zijlstra <peterz@...radead.org>
Cc:	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
	John Stultz <john.stultz@...aro.org>,
	Ingo Molnar <mingo@...hat.com>,
	lkml <linux-kernel@...r.kernel.org>,
	Dmitry Shmidt <dimitrysh@...gle.com>,
	Rom Lemarchand <romlem@...gle.com>,
	Colin Cross <ccross@...gle.com>, Todd Kjos <tkjos@...gle.com>,
	Oleg Nesterov <oleg@...hat.com>
Subject: Re: Severe performance regression w/ 4.4+ on Android due to cgroup
 locking changes

On Thu, Jul 14, 2016 at 08:49:56AM +0200, Peter Zijlstra wrote:
> On Wed, Jul 13, 2016 at 06:01:28PM -0400, Tejun Heo wrote:
> 
> > Technically, I think the lglock approach would be better here given
> > the combination of requirements; however, it's quite a bit more code
> > which would likely require some sophistications down the line (like
> > blocking new readers first at the start of down_write). 
> 
> So the immediate problem with lg style locks is that the 'local' lock
> will not stay local since these are preemptible locks we can get
> migrations etc..
> 
> All fixable, but still.

In this case, the locks are read-locked only across operations which
change process hierarchy.  They'll occasionally get migrated while
holding the lock for sure but not often enough to matter.

> > If we have to
> > go there, we'll go there but for now I think it'd be simpler to
> > conditionally switch to the expedited operations.  It can be a config
> > option which is selected by !RT as you suggested.  If anyone hits an
> > actual issue with that, we can go for the lglock thing.
> 
> So the main objection I have is that this isn't a fundamental fix, this
> only cures things because Android only runs on small machines.
>
> If someone with a big computer tries to do the same things we're up some
> creek without no paddle. There's just no way we can make a global writer
> 'fast'.

How so?  As the number of cores increases, it'll get proportionally
more expensive as the same operation is performed on more CPUs;
however, the latency is dependent on the slowest one and it'll get
higher more often with more number of CPUs but not drastically.
Latency won't go up proportionally with the number of CPUs.  For the
most part, we're paying more in terms of processing overhead, not
latency.

Thanks.

-- 
tejun