On Tue, Jul 29, 2014 at 09:22:36AM -0700, Paul E. McKenney wrote: > On Tue, Jul 29, 2014 at 09:55:36AM +0200, Peter Zijlstra wrote: > > On Mon, Jul 28, 2014 at 03:56:13PM -0700, Paul E. McKenney wrote: > > > From: "Paul E. McKenney" <paul...@linux.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. > > Fair enough. ;-) > > > > 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. > > When Joe Hacker gets stall warning messages due to loops in the kernel > that contain cond_resched(), that is a hint that cond_resched_rcu_qs() > is required. These stall warnings can occur when using RCU-tasks and when > using normal RCU in NO_HZ_FULL kernels in cases where the scheduling-clock > interrupt is left off while executing a long code path in the kernel. > (Of course, in both cases, another eminently reasonable fix is to shorten > the offending code path in the kernel.) > > I should add words to that effect to Documentation/RCU/stallwarn.txt, > shouldn't I? Done.
No, but why can't we make the regular cond_resched() do this? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
