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: <20160714151425.GK15005@htj.duckdns.org>
Date:	Thu, 14 Jul 2016 11:14:25 -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 02:11:01PM +0200, Peter Zijlstra wrote:
> > 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.
> 
> A global lock on 4 or 8 socket machines with all 200+ cpus trying to
> use it really stinks.

That's why we're using percpu lock here.  With the right
implementation the write locking latency shouldn't be proportional to
the number of cores.  The total processing overhead could be.

> Remember, they switch cgroups at really rather high rates here, because
> of that binder stuff. I don't see how you can defend a global lock here
> :/ Global locks only work when writers are extremely rare, and clearly
> that premise is false.

This is one of the most eccentric uses and if I'm not mistaken they
were even doing memcg charge immigration on fore <-> background
switches which involve re-labeling each page.  And even with binder,
migration isn't nearly hot enough to matter for the most part even
when it's emitting IPIs globally.

We can split the locking but it just isn't necessary at this point.
More downsides than upsides.  If we actually need that, let's go
there.

Thanks.

-- 
tejun