Just setting timer_slop=2ms has similar effect as (or say slightly better than,
1~2W less) setting timer_slop=1ms, with no code modifications.
But with your suggested way(patch attached) and setting timer_slop=1ms, the win
is even bigger than my original patch, saving 4W more than my original patch.
Jimmy
Keir Fraser wrote:
> Thanks. Also, beyond a certain point, you have to consider whether
> just setting timer_slop=2ms (or whatever) has similar effect on
> performance and power saving, with no code modifications. :-) It's
> not like slop=1ms is some super-special value or anything, arrived at
> with scientific exactitude.
>
> But the approach I suggect at least seems internally consistent and I
> will considewr it if it gives you similar power wins to what your
> original patch gave you.
>
> -- Keir
>
> On 09/12/2009 12:34, "Wei, Gang" <gang.wei@xxxxxxxxx> wrote:
>
>> On a Xeon 5500 server w/ 2S/8C/16T, w/ HT off, starting 8 rhel5 UP
>> hvm guests, idling, I saw 22W (10%) power saving after apply this
>> patch and specify timer_slop=1ms on xen grub line. It saves 10W more
>> than the case only specify timer_slop=1ms but w\o this patch.
>>
>> Yes, your suggestion do remove the double dipping. I will give it a
>> try.
>>
>> Jimmy
>>
>> Keir Fraser wrote:
>>> How much of a win is this? The per-cpu timer_deadline is already
>>> calculated based on slop, so doing it again in hpet.c is kind of
>>> like double dipping. I think we can validly do some improvements in
>>> hpet.c however: e.g., by exposing a per-cpu timer deadline range
>>> (deadline_start,deadline_end) and setting up HPET to fire on the
>>> earliest deadline_end. Then broadcast to all CPUs with
>>> deadline_start < NOW() when the HPET fires.
>>>
>>> The deadline range would be computed as follows in timer.c, in the
>>> !ts->overflow case in the softirq handler:
>>> timer_deadline_start = start (i.e., same as timer_deadline today)
>>> timer_deadline_end = end In the (incredibly uncommon) ts->overflow
>>> case we can just set
>>> timer_deadline_start=timer_deadline_end=timer_deadline.
>>>
>>> Perhaps give that a go: I would find that more acceptable at least,
>>> but all of this really depends on what benchmark improvements you
>>> are seeing.
>>>
>>> -- Keir
>>>
>>> On 09/12/2009 09:33, "Wei, Gang" <gang.wei@xxxxxxxxx> wrote:
>>>
>>>> x86: add a range for hpet broadcast
>>>>
>>>> Apply a range timer like range to hpet broadcast, so that timer
>>>> expires within timer_slop ns across idle CPUs are capable to be
>>>> aligned to reduce hpet intrs, and save idle power.
>>>>
>>>> Signed-off-by: Wei Gang <gang.wei@xxxxxxxxx>
hpet-range-v2.patch
Description: hpet-range-v2.patch
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home