[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140813081215.GB9918@twins.programming.kicks-ass.net>
Date: Wed, 13 Aug 2014 10:12:15 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
Cc: linux-kernel@...r.kernel.org, mingo@...nel.org,
laijs@...fujitsu.com, dipankar@...ibm.com,
akpm@...ux-foundation.org, mathieu.desnoyers@...icios.com,
josh@...htriplett.org, tglx@...utronix.de, rostedt@...dmis.org,
dhowells@...hat.com, edumazet@...gle.com, dvhart@...ux.intel.com,
fweisbec@...il.com, oleg@...hat.com, bobby.prani@...il.com
Subject: Re: [PATCH v5 tip/core/rcu 15/16] rcu: Make RCU-tasks wait for idle
tasks
On Mon, Aug 11, 2014 at 03:49:04PM -0700, Paul E. McKenney wrote:
> From: "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
>
> Because idle-task code may need to be patched, RCU-tasks need to wait
> for idle tasks to schedule. This commit therefore detects this case
> via context switch. Block CPU hotplug during this time to avoid sending
> IPIs to offline CPUs.
>
> Note that checking for changes in the dyntick-idle counters is tempting,
> but wrong. The reason that it is wrong is that a interrupt or NMI can
> increment these counters without necessarily allowing the idle tasks to
> make any forward progress.
I'm going to NAK this.. with that rcu_idle patch I send there's
typically only a single idle function thats out of bounds and if its
more it can be made that with a bit of tlc to the cpuidle driver in
question.
This needs _FAR_ more justification than a maybe and a want.
Content of type "application/pgp-signature" skipped
Powered by blists - more mailing lists