[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140729075536.GZ19379@twins.programming.kicks-ass.net>
Date: Tue, 29 Jul 2014 09:55:36 +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 RFC tip/core/rcu 2/9] rcu: Provide cond_resched_rcu_qs()
to force quiescent states in long loops
On Mon, Jul 28, 2014 at 03:56:13PM -0700, Paul E. McKenney wrote:
> From: "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
>
> RCU-tasks requires the occasional voluntary context switch
> from CPU-bound in-kernel tasks. In some cases, this requires
> instrumenting cond_resched(). However, there is some reluctance
> to countenance unconditionally instrumenting cond_resched() (see
> http://lwn.net/Articles/603252/),
No, if its a good reason mention it, if not ignore it.
> so this commit creates a separate
> cond_resched_rcu_qs() that may be used in place of cond_resched() in
> locations prone to long-duration in-kernel looping.
Sounds like a pain and a recipe for mistakes. How is joe kernel hacker
supposed to 1) know about this new api, and 2) decide which to use?
Heck, even I wouldn't know, and I just read the damn patch.
Content of type "application/pgp-signature" skipped
Powered by blists - more mailing lists