On Wed, May 15, 2013 at 09:37:00AM -0700, Paul E. McKenney wrote: > The need is to detect that an idle CPU is idle without making it do > anything. To do otherwise would kill battery lifetime and introduce > OS jitter.
Not anything isn't leaving us much room to wriggle, we could maybe try and do a wee bit without people shooting us :-) In fact, looking at rcu_idle_enter() its very much not an empty function. > This other CPU must be able to correctly detect idle CPUs regardless of > how long they have been idle. In particular, it is necessary to detect > CPUs that were idle at the start of the current grace period and have > remained idle throughout the entirety of the current grace period. OK, so continuing this hypothetical merry go round :-) Since RCU is a global endeavour, I'm assuming there is a global GP sequence number. Could we not stamp the CPU with the current GP# in rcu_idle_enter(). > A CPU might transition between idle and non-idle states at any time. > Therefore, if RCU collects a given CPU's idleness state during a given > grace period, it must be very careful to avoid relying on that state > during some other grace period. However, if we know during which GP it became idle, we know we can ignore it for all GPs thereafter, right? > Therefore, from what I can see, unless all CPUs explicitly report a > quiescent state in a timely fashion during a given grace period (in > which case each CPU was non-idle at some point during that grace period), > there is no alternative to polling RCU's per-CPU rcu_dynticks structures > during that grace period. In particular, if at least one CPU remained > idle throughout that grace period, it will be necessary to poll. Agreed.. > Of course, during boot time, there are often long time periods during > which at least one CPU remains idle. Therefore, we can expect many > boot-time grace periods to delay for at least one FQS time period. > > OK, so how much delay does this cause? Oh, I'm so way past that, it is a neat puzzle by now ;-) -- 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/
