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/
Home Products Support Community News


RE: [Xen-devel] Re: TSC scaling and softtsc reprise, and PROPOSAL

To: "Tian, Kevin" <kevin.tian@xxxxxxxxx>, Jeremy Fitzhardinge <jeremy@xxxxxxxx>, Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Subject: RE: [Xen-devel] Re: TSC scaling and softtsc reprise, and PROPOSAL
From: Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>
Date: Thu, 6 Aug 2009 14:13:06 -0700 (PDT)
Cc: Ian Pratt <Ian.Pratt@xxxxxxxxxxxxx>, "Xen-Devel \(E-mail\)" <xen-devel@xxxxxxxxxxxxxxxxxxx>, "Dong, Eddie" <eddie.dong@xxxxxxxxx>, "Zhang, Xiantao" <xiantao.zhang@xxxxxxxxx>, John Levon <levon@xxxxxxxxxxxxxxxxx>
Delivery-date: Thu, 06 Aug 2009 14:13:43 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <0A882F4D99BBF6449D58E61AAFD7EDD630C9AAB5@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
Well actually, "how Linux handles this" is subject to
a dizzying matrix of hardware-dependent, CONFIG_-dependent,
linux-boot-parameter-dependent choices
that have evolved/changed at nearly every Linux
kernel version.  While it might be useful to steal
some recent Linux code to help determine if it is
safe to build Xen system time on top of TSC on some
processors, I don't know if Linux is of much use as
a design guide for how to expose TSC to guests/apps,
especially when said guests/apps may be moving back and
forth between hardware with widely varying TSC

But, yes, as Kevin points out, on some recent versions
of Linux on some hardware with some CONFIG/boot-params,
the kernel does indeed try to use TSC as a reliable
foundation for delivering ticks and gettimeofday-ish

> -----Original Message-----
> From: Tian, Kevin [mailto:kevin.tian@xxxxxxxxx]
> Sent: Tuesday, August 04, 2009 11:36 PM
> To: Jeremy Fitzhardinge; Keir Fraser
> Cc: Dan Magenheimer; Xen-Devel (E-mail); Dong, Eddie; John
> Levon; Ian Pratt; Zhang, Xiantao
> Subject: RE: [Xen-devel] Re: TSC scaling and softtsc reprise,
> >From: Jeremy Fitzhardinge
> >Sent: 2009?8?5? 8:06
> >
> >On 07/24/09 01:04, Keir Fraser wrote:
> >> Okay, so the issue you are worried about is not specific to
> >Xen. So how is
> >> native Linux tackling this, for example?
> >>  
> >
> >Linux will use the tsc where possible, but regularly assesses its
> >perceived accuracy and will move to a different clocksource
> if the tsc
> >appears to the playing up.  I don't think it ever assumes the tsc is
> >synced between CPU/cores.
> It cares. See tsc_sync.c under x86 arch, where unsynced warps
> mark tsc as unstable.
> Thanks,
> Kevin
> >
> >It allows rdtsc from usermode, but it is generally considered
> >to be very
> >buggy and ill-defined behaviour.  It makes no attempt to
> make usermode
> >rdtsc in any way meaningful.  The exception is the vgettimeofday
> >vsyscall which does Xen-like timekeeping, in which it gets
> the tsc,cpu
> >tuple atomically, then scales it with timing parameters from
> >the kernel.
> >
> >    J
> >
> >_______________________________________________
> >Xen-devel mailing list
> >Xen-devel@xxxxxxxxxxxxxxxxxxx
> >http://lists.xensource.com/xen-devel
> >

Xen-devel mailing list