[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CALAqxLU880FGWM+sCha1LAi8KCtzreG2jrMEPU92PSHy2tOOJg@mail.gmail.com>
Date: Wed, 13 Jul 2016 15:39:37 -0700
From: John Stultz <john.stultz@...aro.org>
To: Paul McKenney <paulmck@...ux.vnet.ibm.com>
Cc: Tejun Heo <tj@...nel.org>, Peter Zijlstra <peterz@...radead.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 Wed, Jul 13, 2016 at 3:17 PM, Paul E. McKenney
<paulmck@...ux.vnet.ibm.com> wrote:
> On Wed, Jul 13, 2016 at 02:46:37PM -0700, John Stultz wrote:
>> On Wed, Jul 13, 2016 at 2:42 PM, Paul E. McKenney
>> <paulmck@...ux.vnet.ibm.com> wrote:
>> > On Wed, Jul 13, 2016 at 02:18:41PM -0700, Paul E. McKenney wrote:
>> >> On Wed, Jul 13, 2016 at 05:05:26PM -0400, Tejun Heo wrote:
>> >> > On Wed, Jul 13, 2016 at 02:03:15PM -0700, Paul E. McKenney wrote:
>> >> > > Take the patch that I just sent out and make the choice of normal
>> >> > > vs. expedited depend on CONFIG_PREEMPT_RT or whatever the -rt guys are
>> >> > > calling it these days. Is there a low-latency Kconfig option other
>> >> > > than CONFIG_NO_HZ_FULL?
>> >> >
>> >> > Sounds like a plan to me.
>> >>
>> >> I like the way we like each other's idea. Mutually assured laziness? ;-)
>> >
>> > But here is what mine might look like. Untested, probably does
>> > not even build. Note that the default is -no- expediting, use the
>> > rcusync.expedited kernel parameter to enable it.
>>
>> I was working on something similar, but using a config option. Would
>> adding a config option for the default make sense here, since I'd
>> probably prefer to have one less thing to always specify on the
>> cmdline?
>
> As long as you don't mind it depending on CONFIG_RCU_EXPERT, no problem.
>
> Perhaps like the following, on top of the previous patch?
>
> Or if you are going to put it in defconfig files only, I can make it
> so that it isn't changeable at menuconfig time.
I think having it discoverable via menuconfig is useful, and I've got
no objections to it being under RCU_EXPERT
(assuming I don't badly muck up my RCU settings accidentally :).
I only had that one nit about maybe wanting to put something in dmesg
when we're using the expedited methods.
But otherwise both patches look great and are working well!
Do you mind marking them both for stable 4.4+?
Tested-by: John Stultz <john.stultz@...aro.org>
Acked-by: John Stultz <john.stultz@...aro.org>
Also, do make sure Dmitry gets the reported-by credit for the first patch.
thanks
-john
Powered by blists - more mailing lists