Re: [Xen-devel] [PATCH 5/5] xen: RCU: avoid busy waiting until the end of grace period.

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

On Tue, 1 Aug 2017, Dario Faggioli wrote:
> 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?

In terms of power saving and CPU sleep states, 10ms is not much to sleep
for. I wonder if there are any power saving benefits in sleeping for
only 10ms (especially on x86 where entering and exiting CPU sleep states
takes longer, to be confirmed).  We might as well do the thing we need
to do immediately? I guess we cannot do that?

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