Re: [PATCH v3 6/6] xen: try to prevent idle timer from firing too often.

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

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

On Tue, 2017-08-29 at 17:30 +0100, George Dunlap wrote:
> On 08/18/2017 07:04 PM, Dario Faggioli wrote:
> > 
> > What we're trying to avoid is one of those idle CPUs to
> > wake up, only to discover that the grace period is still
> > running, and that it hence could have be slept longer
> > (saving more power).
> 
> So I think we're only taking about one or two extra wakeups per cpu
> maximum -- if this even happens at all.
> 
Yep, indeed.

> Wouldn't it be better to first add a performance counter, and check
> to
> see if and how often this situation happens?
> 
The counter is there already. It's rcu_idle_timer ("RCU: idle_timer").

> > This patch implements an heuristic aimed at achieving
> > that, at the price of having to call cpumask_weight() on
> > the 'entering idle' path, on CPUs with queued callbacks.
> 
> The heuristic seems a bit strange to me too: why would each cpu
> increase
> the grace period in a linear fashion?  I haven't looked at the grace
> period code, but I would have expected each one to be independent;
> and
> so there'd be a "diminishing returns" effect when adding more cpus.
> 
I like the idea, in general. Let me just double check whether I'm
understanding what you're suggesting properly.

First of all, what do you mean with "adding more cpus"? Adding to what?
 The timer is useful when a CPU, which is participating in the grace
period, goes idle, while the grace period is not finished. From that
point on, the number of CPUs participating to _that_ grace period will
monotonically decrease, until it reaches zero. So what does 'adding'
means in this context?

> If we have to have something like this (which I'm not at all
> convinced
> we do), I would think having a single number which self-adjusted so
> that
> the number of 'misses' was around 1% would be a good balance.  What
> about a heuristic like this:
> 
> 1. If the timer goes off and the grace period isn't over, add 10ms to
> the timer period
> 2. If the timer goes off and the grace period *is* over, subtract
> 100us
> from the timer period
> 
So, let's say we start with a period of 1ms. First time RCU is used,
the timer fires twice: the first time it finds the grace period is
still ongoning --and hence the period becomes 11ms-- while the seconds
finds it over --so the period is now 10.9ms.

Next time RCU is used, if the timer is necessary, we use 10.9ms.

Am I getting your proposal right?

If yes, do we allow the period to become smaller than the initial value
(1ms, in the example above). I'd say we better not (or that we at least
set a lower bound), or, given enough occurrences of cases when the
timer fires and finds the grace period to be over in a row, the period
can become 0!

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