On Thu, 2012-09-06 at 09:47 -0700, Paul E. McKenney wrote: > The key point is "would simple put RCU into extended quiescent state". > This can only happen if the CPU has no callbacks. If the CPU does have > callbacks, then RCU will need to do some work to advance the callbacks. > Advancing the callbacks requires that RCU periodically do work on that > CPU, resulting in OS jitter.
But since its then not actually in adaptive-tick mode (the tick is still running) who cares? It will only disable the tick once all preconditions are met, this includes RCU being in extended qs, so until that time... > > That way you could run the entire state thing from a kthread with random > > affinity, all 'per-cpu' data would still be fine since only the one > > kthread will access it, even though locality might suffer somewhat. > > Well, the current patch set does move much of the grace-period machinery > to a kthread. Much of the remaining work needs to remain on the CPUs > (at least those not in an extended quiescent state) in order to keep > the overhead of the read-side primitives and scheduler hooks inexpensive. Ah indeed, what you're saying is that the data required by those hooks needs to be accessed locally in order to avoid proper atomic ops. So then you do indeed need to break the state machine into two parts, and I guess that's the bit you're struggling with. Still I would not make this more complex than it needs to be, if the tick is running we can use this to drive the state machine, if its not, we are in extended qs and we don't need to drive the tick. -- 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/
