On Fri, Oct 04, 2013 at 09:03:52AM -0700, Paul E. McKenney wrote: > The problem exists, but NOCB made it much more probable. With non-NOCB > kernels, an irq-disabled call_rcu() invocation does a wake_up() only if > there are more than 10,000 callbacks stacked up on the CPU. With a NOCB > kernel, the wake_up() happens on the first callback.
Oh I see.. so I was hoping this was some NOCB crackbrained damage we could still 'fix'. And that wakeup is because we moved grace-period advancing into kthreads, right? > I am not too happy about the complexity of deferring, but maybe it is > the right approach, at least assuming perf isn't going to whack me > with a timer lock. ;-) I'm not too thrilled about trying to move the call_rcu() usage either. > Any other approaches that I am missing? Probably; so the regular no-NOCB would be easy to work around by providing me a call_rcu variant that never does the wakeup. NOCB might be a little more difficult; depending on the reason why it needs to do this wakeup on every single invocation; that seems particularly expensive. Man, RCU was so much easier when all it was was a strict per-cpu state with timer-interrupt driven state machine; non of all this nonsense. -- 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/
