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

[Tejun Heo]

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