Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1469747

Re: [PATCH v2] locking/percpu-rwsem: Optimize readers and reduce global impact

From Tejun Heo <tj@kernel.org>
Newsgroups linux.kernel
Subject Re: [PATCH v2] locking/percpu-rwsem: Optimize readers and reduce global impact
Date 2016-08-24 23:40 +0200
Message-ID <s9O3T-87h-9@gated-at.bofh.it> (permalink)
References (3 earlier) <s4Gqm-b4-47@gated-at.bofh.it> <s5wfg-1k5-7@gated-at.bofh.it> <s5wfg-1k5-9@gated-at.bofh.it> <s5wfg-1k5-5@gated-at.bofh.it> <s9NKy-7XX-29@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


Hello, John.

On Wed, Aug 24, 2016 at 02:16:52PM -0700, John Stultz wrote:
> Hey Peter, Tejun, Oleg,
>   So while you're tweaks for the percpu-rwsem have greatly helped the
> regression folks were seeing (many thanks, by the way), as noted
> above, the performance regression with the global lock compared to
> earlier kernels is still ~3x slower (though again, much better then
> the 80x slower that was seen earlier).
> 
> So I was wondering if patches to go back to the per signal_struct
> locking would still be considered? Or is the global lock approach the
> only way forward?

We can't simply revert but we can make the lock per signal_struct
again.  It's just that it'd be quite a bit more complex (but, again,
if we need it...) and for cases where migrations aren't as frequent
percpu-rwsem would be at least a bit lower overhead.  Can you please
test with the following patch applied just in case?

 https://git.kernel.org/cgit/linux/kernel/git/tj/cgroup.git/commit/?h=for-4.8-fixes&id=568ac888215c7fb2fabe8ea739b00ec3c1f5d440

> At a higher level, I'm worried that Android's use of cgroups as a
> priority enforcement mechanism is at odds with developers focusing on
> it as a container enforcement mechanism, as in the latter its not
> common for tasks to change between cgroups, but with the former
> priority adjustments are quite common.

It has been at odds as long as android existed.  cgroup used to have
synchronous synchronize_rcu() in the migration path which android
kernel simply deleted (didn't break android's use case), re-labeling
every page's memcg ownership on foreground and background switches
(does it still do that? it's simply unworkable) and so on.

I find it difficult to believe that android's requirements can be
satisfied only through moving processes around.  cgroup usage model is
affected by container use cases but isn't limited to it.  If android
is willing to change, I'd be more than happy to work with you and
solve obstacles.  If not, we'll surely try not to break it anymore
than it has always been broken.

Thanks.

-- 
tejun

Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread


Thread

Re: [PATCH v2] locking/percpu-rwsem: Optimize readers and reduce  global impact Om Dhyade <odhyade@codeaurora.org> - 2016-08-13 03:50 +0200
  Re: [PATCH v2] locking/percpu-rwsem: Optimize readers and reduce  global impact John Stultz <john.stultz@linaro.org> - 2016-08-24 23:20 +0200
    Re: [PATCH v2] locking/percpu-rwsem: Optimize readers and reduce  global impact Tejun Heo <tj@kernel.org> - 2016-08-24 23:40 +0200
      Re: [PATCH v2] locking/percpu-rwsem: Optimize readers and reduce  global impact John Stultz <john.stultz@linaro.org> - 2016-08-25 01:00 +0200
      Re: [PATCH v2] locking/percpu-rwsem: Optimize readers and reduce  global impact John Stultz <john.stultz@linaro.org> - 2016-08-26 04:30 +0200
        Re: [PATCH v2] locking/percpu-rwsem: Optimize readers and reduce  global impact Tejun Heo <tj@kernel.org> - 2016-08-26 15:00 +0200
          Re: [PATCH v2] locking/percpu-rwsem: Optimize readers and reduce  global impact Dmitry Shmidt <dimitrysh@google.com> - 2016-08-26 18:50 +0200
            Re: [PATCH v2] locking/percpu-rwsem: Optimize readers and reduce  global impact Om Dhyade <odhyade@codeaurora.org> - 2016-08-26 22:20 +0200

csiph-web