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

[George Dunlap <george.dunlap@xxxxxxxxxx>]

On 08/18/2017 07:04 PM, Dario Faggioli wrote:
> Idea is: the more CPUs are still active in a grace period,
> the more we can wait to check whether it's time to invoke
> the callbacks (on those CPUs that have already quiesced,
> are idle, and have callbacks queued).
> 
> 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).

But this will only happen:
1. If the cpu in question had just been running
2. Until the grace period is actually finished, at which point it will
stop entirely again (since idle vcpus are filtered out now).

So I think we're only taking about one or two extra wakeups per cpu
maximum -- if this even happens at all.

Wouldn't it be better to first add a performance counter, and check to
see if and how often this situation happens?

> 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.

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

The above should self-adjust so that around 1% of timers miss.

Thoughts?

 -George

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