Re: [PATCH v2 3/6] xen: RCU/x86/ARM: discount CPUs that were idle when grace period started.

[Dario Faggioli <dario.faggioli@citrix.com>]

[-- Attachment #1.1: Type: text/plain, Size: 1942 bytes --]

On Thu, 2017-08-17 at 14:03 +0100, Tim Deegan wrote:
> At 18:45 +0200 on 16 Aug (1502909149), Dario Faggioli wrote:
> > +
> > +/*
> > + * The CPU is becoming idle, so no more read side critical
> > + * sections, and one more step toward grace period.
> > + */
> > +void rcu_idle_enter(unsigned int cpu)
> > +{
> > +    /*
> > +     * During non-boot CPU bringup and resume, until this function
> > is
> > +     * called for the first time, it's fine to find our bit
> > already set.
> > +     */
> > +    ASSERT(!cpumask_test_cpu(cpu, &rcu_ctrlblk.idle_cpumask) ||
> > +           (system_state < SYS_STATE_active || system_state >=
> > SYS_STATE_resume));
> 
> Does every newly started CPU immediately idle?  If not, then it might
> run in an RCU read section but excluded from the grace period
> mechanism.
> 
They do call startup_cpu_idle_loop() pretty soon, yes (right at the end
of start_secondary(), on both x86 and ARM). But technically, yes, there
is a window for that.

> It seems like it would be better to start with the idle_cpumask
> empty,
> and rely on online_cpumask to exclude CPUs that aren't running.
>
I thought about that too, but then ended up doing it the other way
(i.e., having the mask fully set).

Now, I just tried to initialize it to "all clear"... It works, and I
have to admit that I like it better. :-)

As I'm going on vacations for a couple of weeks, I'll send v3 right
now, with just this changed, so it could even be checked-in, if others
too are happy with this, and the rest of the patches (if not, we'll
talk about it when I'm back :-P).

Thanks and Regards,
Dario
-- 
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)

[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

[-- Attachment #2: Type: text/plain, Size: 127 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel