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 <mr.yuke@xxxxxxxxx>, Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Subject: RE: [Xen-devel] [PATCH 0/2] range timer support
From: Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>
Date: Wed, 29 Oct 2008 15:53:37 +0000 (GMT)
Cc: "Liu, Jinsong" <jinsong.liu@xxxxxxxxx>, "Tian, Kevin" <kevin.tian@xxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx, Dave Winchell <dwinchell@xxxxxxxxxxxxxxx>, "Yu, Ke" <ke.yu@xxxxxxxxx>, "Wei, Gang" <gang.wei@xxxxxxxxx>
Delivery-date: Wed, 29 Oct 2008 08:54:41 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <631d03500810290345v68a1bbf0t1ba236cace1a0334@xxxxxxxxxxxxxx>
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
> here is my two cents just for your reference. I have tried range timer
> in several places:
> <snip>
> - HVM virtual period timer: this timer allow expires behind deadline a
> bit, because it has logic to handling missing ticks. so the range can
> be [deadline, deadline + period/n]. to be more conservative, it is
> safe to add up limit of 1ms. the 1ms comes from the commodity OS
> frequency, e.g. Linux kernel has 1000/250/100 HZ, and windows has 64
> HZ, 1ms should meet the up limit of 1000HZ.

A reminder that hvm HPET usage by some Linux kernels has a
problem where delivery of a tick sooner than expected can
cause the guests apparent time to advance too quickly.
Dave Winchell submitted a patch for this some time back
that didn't get accepted (for various reasons) and I'm
not sure if this range timer implementation will make it
better or worse.

But I'm pretty sure that if ticks are delivered at:

T+0d+3s, T+1d+2s, T+2d+1s

where d=1/Hz and s=slop, the problem will be observed.

Dave, can you comment?

Dan

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