mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Tejun Heo <tj@kernel.org>
To: John Stultz <john.stultz@linaro.org>
Cc: Peter Zijlstra <peterz@infradead.org>,
	Oleg Nesterov <oleg@redhat.com>,
	Om Dhyade <odhyade@codeaurora.org>,
	"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
	Ingo Molnar <mingo@kernel.org>,
	lkml <linux-kernel@vger.kernel.org>,
	Dmitry Shmidt <dimitrysh@google.com>,
	Rom Lemarchand <romlem@google.com>,
	Colin Cross <ccross@google.com>, Todd Kjos <tkjos@google.com>
Subject: Re: [PATCH v2] locking/percpu-rwsem: Optimize readers and reduce global impact
Date: Wed, 24 Aug 2016 17:30:51 -0400	[thread overview]
Message-ID: <20160824213051.GX8185@htj.duckdns.org> (raw)
In-Reply-To: <CALAqxLVq53+Sb1t_aGH9ngW5m4FEDeaoidUwhqxzUU=qc_bNBg@mail.gmail.com>

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

  reply	other threads:[~2016-08-24 21:30 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-08-09  9:51 Peter Zijlstra
2016-08-09 23:47 ` John Stultz
2016-08-10  7:56   ` Peter Zijlstra
2016-08-10 17:09     ` Oleg Nesterov
     [not found]       ` <CAH7ZN-zXrenrbbcmvZ+biNozYe21jw6fULopG=g9-xRwWHE6nw@mail.gmail.com>
     [not found]         ` <5a2cc178ee03466fa3b104f8f28b44ff@NASANEXM02C.na.qualcomm.com>
2016-08-13  1:44           ` Om Dhyade
2016-08-24 21:16             ` John Stultz
2016-08-24 21:30               ` Tejun Heo [this message]
2016-08-24 22:50                 ` John Stultz
2016-08-26  2:14                 ` John Stultz
2016-08-26 12:51                   ` Tejun Heo
2016-08-26 16:47                     ` Dmitry Shmidt
2016-08-26 20:10                       ` Om Dhyade
2016-08-11 16:54 ` [PATCH] cgroup: avoid synchronize_sched() in __cgroup_procs_write() Oleg Nesterov
2016-08-18 10:59   ` [tip:locking/core] locking, rcu, cgroup: Avoid " tip-bot for Peter Zijlstra
2016-08-18 13:41   ` tip-bot for Peter Zijlstra
2016-08-31  5:21 ` [v2] locking/percpu-rwsem: Optimize readers and reduce global impact Guenter Roeck
2016-08-31  8:09   ` Peter Zijlstra
2016-08-31 13:41     ` Guenter Roeck
2016-08-31 13:47       ` Guenter Roeck

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160824213051.GX8185@htj.duckdns.org \
    --to=tj@kernel.org \
    --cc=ccross@google.com \
    --cc=dimitrysh@google.com \
    --cc=john.stultz@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=odhyade@codeaurora.org \
    --cc=oleg@redhat.com \
    --cc=paulmck@linux.vnet.ibm.com \
    --cc=peterz@infradead.org \
    --cc=romlem@google.com \
    --cc=tkjos@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®