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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ