[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CALAqxLWoMVzUuSJM0uKXO25s4toXMceLFdKngzGNsAX7-+q0FA@mail.gmail.com>
Date: Wed, 13 Jul 2016 14:46: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 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?
thanks
-john
Powered by blists - more mailing lists