Hi,
At 10:01 +0200 on 27 Jul (1501149684), Dario Faggioli wrote:
> In Xen, that is impossible, and that's particularly problematic
> when system is idle (or lightly loaded) systems, as CPUs that
> are idle may never have the chance to tell RCU about their
> quiescence, and grace periods could extend indefinitely!
[...]
> The first step for fixing this situation is for RCU to record,
> at the beginning of a grace period, which CPUs are already idle.
> In fact, being idle, they can't be in the middle of any read-side
> critical section, and we don't have to wait for them to declare
> a grace period finished.
AIUI this patch fixes a bug where:
- a CPU is idle/asleep;
- it is added to the cpumask of a new RCU grace period; and
- because the CPU is asleep, the grace period never ends.
Have I understood?
I think we might be left with a race condition:
- CPU A is about to idle. It runs the RCU softirq and
clears itself from the current grace period.
- CPU B ends the grace period and starts a new one.
- CPU A calls rcu_idle_enter() and sleeps.
- The new grace period never ends.
Is that fixed by your later rcu_idle_timer patch? AIUI that's only
invoked when the calling CPU has pending RCU callbacks.
Or can it be fixed here by something like this in rcu_idle_enter?
- lock rcp->lock
- add ourselves to the idle mask
- if we are in rcp->cpumask:
- cpu_quiet()
- unlock rcp->lock
There's also the code at the top of rcu_check_quiescent_state() that
requres _two_ idle states per batch. I don't know what race that's
protecting against so I don't know whether we need to worry about it
here as well. :)
Cheers,
Tim.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
