On Sun, Sep 21, 2008 at 01:09:51PM +0200, Manfred Spraul wrote:
That has been one of my biggest questions about your approach, that and
the need to hit holdouts with resched IPI. (Though perhaps you have
worked out another way around this.)
Agreed. I could use this approach as well, having each CPU set and clear
its qsmaskinit bit on every exit from and entry to dynticks idle state,
but see below...
In your case, you would need to carefully keep state so that a CPU
entering dynticks idle mode would know whether or not it needed to
respond to the current grace period -- but you need this in any case,
so no added complexity as far as I can see.
Yep! Hence my reluctance to add overhead to the dynticks side of the
algorithm.
Indeed, this is the easy case for both of our approaches.
I use an analogous algorithm, as the qsinitmask values might change while
setting up for the next quiescent state. The tough part of this was
correctly handling races between setting up for the quiescent state and
onlining/offlining CPUs (and, in your case, CPUs entering/leaving dynticks
idle mode). I chose to use a global lock that excludes online/offline
and starting a quiescent state (except in the case where there are so
few CPUs that there is but one rcu_node structure, in which case that
structure's lock suffices, so that onofflock need not be acquired).
But although acquiring a global lock is reasonable for CPU online/offline
(as there can be but one such operation at a time), it would be quite
painful for the dynticks case.
Of course, I might be able to avoid the need for this global lock if I
were willing to acquire the interior-node rcu_node locks when setting
up for the next grace period. But this would require me to put in a
cleanup step after grace-period setup, as some set of dyntick operations
might otherwise end the grace period before it is fully initialized.
This could potentially result in two different CPUs setting up grace
periods concurrently (yuck!). Worse yet, the grace period could end
while the initialization was only halfway through the leaves, so that
the CPU doing the initialization would need to recognize this and stop
further initialization -- and, again, clean up (yuck^2!).
Your two-phase approach might (or might not) avoid this issue.
Thanx, Paul
--
