[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Xen-devel] RE: [PATCH]x86: add a range for hpet broadcast


  • To: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>, Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • From: "Wei, Gang" <gang.wei@xxxxxxxxx>
  • Date: Thu, 10 Dec 2009 00:25:59 +0800
  • Accept-language: en-US
  • Acceptlanguage: en-US
  • Cc:
  • Delivery-date: Wed, 09 Dec 2009 08:26:28 -0800
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: Acp4sqXoSopeIMedTaiA9e0L2HFpxQADZH79AAG+pBAAAmqknQAFqJ4g
  • Thread-topic: [PATCH]x86: add a range for hpet broadcast

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>

Attachment: hpet-range-v2.patch
Description: hpet-range-v2.patch

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.