WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] [PATCH 0/2] range timer support

To: "Yu, Ke" <ke.yu@xxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH 0/2] range timer support
From: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Date: Thu, 30 Oct 2008 08:28:37 +0000
Cc: "Liu, Jinsong" <jinsong.liu@xxxxxxxxx>, "Tian, Kevin" <kevin.tian@xxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, "Wei, Gang" <gang.wei@xxxxxxxxx>
Delivery-date: Thu, 30 Oct 2008 01:28:50 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <49582C73AC36CC4C8C6C42390304E81C092FCF4709@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Ack5s4BF0I0qvHXHTcCbN8k2fsl5+wAsigPQAAD2N0M=
Thread-topic: [Xen-devel] [PATCH 0/2] range timer support
User-agent: Microsoft-Entourage/11.4.0.080122
On 30/10/08 08:08, "Yu, Ke" <ke.yu@xxxxxxxxx> wrote:

>> Increasing SLOP to 1ms should have the the similar 5% gain, as your
>> analysis, it is the worst case of range timer application in vpt. I
>> can redo the measurement to double confirm.
> 
> I have finished the measurement, when TIME_SLOP increase to 1ms, there is
> similar power consumption gain, this time it is 4% (14.0W vs 14.6W) . By
> theory 1ms TIMER_SLOP should have more gain than the range timer. The
> diferrence may be due to the test environment noise.

It may also be because your patch tends to delay the timer deadline
somewhat, and so by the time it goes off you actually sometimes have one or
two more timers you can deliver in the batch? OTOH it could be experimental
noise as you suggest, and certainly this change gets us pretty close to your
win. We'd have to do further experiments to see if increasing TIMER_SLOP
noticeably degrades system performance, but we'd need to do that with the
range-timer approach too.

One thing: as Dan pointed out, some things don't want to get their timeout
early, but generally callers are much more tolerant of getting timeouts a
bit late. Possibly we should set the timer_deadline to nearest timeout +
TIMER_SLOP, and then when executing timers be strict about not executing
timers early (or at least no more than the existing 50us 'mini' slop)?

Or perhaps actually having range timers in timer.c is worthwhile for future
extensions and for now we can just set every timer to [deadline,
deadline+configurable_global_slop]. Then the existing range-timer mechanism
ought to find a sensible deadline to aim for, only delaying timer events
when there is a benefit to doing so.

I'm thinking out loud. :-)

 -- Keir



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