On Mon, 2017-07-31 at 14:20 -0700, Stefano Stabellini wrote: > On Thu, 27 Jul 2017, Dario Faggioli wrote: > > > > diff --git a/xen/common/rcupdate.c b/xen/common/rcupdate.c > > index f0fdc87..4586f2a 100644 > > --- a/xen/common/rcupdate.c > > +++ b/xen/common/rcupdate.c > > @@ -84,8 +84,14 @@ struct rcu_data { > >      int cpu; > >      struct rcu_head barrier; > >      long            last_rs_qlen;     /* qlen during the last > > resched */ > > + > > +    /* 3) idle CPUs handling */ > > +    struct timer idle_timer; > > +    bool idle_timer_active; > >  }; > >   > > +#define RCU_IDLE_TIMER_PERIOD MILLISECS(10) > > Isn't this a bit too short? How is it chosen? > It's totally arbitrary (and that would be the case for whatever value we choose). Basically, it's how long, at worst, after the actual end of a grace period, a (batch of) callback(s) will be invoked. Currently, on Credit1 on ARM (without my patch, from this series, that suspends the tick) that's (by chance) 30 ms (or whatever value is chosen for Credit1 timeslice). On Credit2 (on both ARM and x86), it's never, but on x86 it (apparently) is 'however frequent time sync rendezvouses happs' (which I don't recall, but it's longer), while on ARM is (potentially) never. I accept suggestions about alternatives values, and I'm certainly fine with adding a comment, containing something along the lines of the explanation above, but I fear it's going to be hard to figure out what value is actually the "absolute best". In Linux (which is where the same 'callback book-keeping' happens for them), a tick with a frequency of 1000Hz (== 1ms) is considered 'low- latency/Deskop/real-time'. For us, as said above, tick --when it's there-- would be 30ms by default. I just went with something in the middle. Also, it's not that we'll have a 10ms periodic timer going on for significant amount of time. In fact we expect it to actually fire just once (for each grace period). It's not 100% guaranteed that it won't be reprogrammed and fire a couple of times, but it should not, in the vast majority of cases. What makes you think it's short? Regards, Dario -- <> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)