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


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

To: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>, Ian Pratt <Ian.Pratt@xxxxxxxxxxxxx>, "Zhang, Xiantao" <xiantao.zhang@xxxxxxxxx>, "Xen-Devel (E-mail)" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: [Xen-devel] RE: TSC scaling and softtsc reprise, and PROPOSAL
From: Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>
Date: Fri, 24 Jul 2009 07:47:51 -0700 (PDT)
Cc: "Dong, Eddie" <eddie.dong@xxxxxxxxx>, John Levon <levon@xxxxxxxxxxxxxxxxx>
Delivery-date: Fri, 24 Jul 2009 07:48:31 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <C68F298A.104C0%keir.fraser@xxxxxxxxxxxxx>
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
> >> Why would you expect host TSC consistency running on Xen to
> >> be worse than
> >> when running on a native OS?
> > 
> > In short, it is because a new class of machine
> > is emerging in the virtualization space that
> > is really a NUMA machine, tries to look like
> > a SMP (non-NUMA) machine by making memory access
> > fast enough that NUMA-ness can be ignored,
> > but for the purposes of time, is still a
> > NUMA machine.
> Okay, so the issue you are worried about is not specific to 
> Xen. So how is
> native Linux tackling this, for example?

I'm not sure that it is, though I'll look into it.

But the difference is that, in a virtual environment,
sometimes it is "safe" to use TSC and sometimes it is
not and, on a LARGE machine, this changes dynamically.
Further, a guest may "originate" on a physical machine
where it is safe and migrate to a physical machine
where it is not.

OS's may ask "is TSC safe", but do so once at startup,
and unfortunately the method to ask is ill-defined.
Applications have no way of asking "is TSC safe" so
either use a one-time startup configuration option
or depend on the OS to make the determination by
always using something like gettimeofdayns().

So if Xen ever responds to an OS asking "is TSC safe",
it should answer it for the whole datacenter (which
itself is not static as new machines might be added
while a VM is live).  As a result, Xen's response must
always be NO.  (Unless, softtsc is the default in which
case the answer can be YES.)

If Xen's response is always NO, apps must use,
indirectly through the OS, a platform timer (which is
probably a lot slower than softtsc!)

So, in the end, to guarantee correctness, high-
frequency-time-stamping apps are going to have slow
access anyway.  And so my conclusion is that we should
always trap TSC, which can guarantee a fixed-frequency
monotonically-increasing timestamp source across all
machines of all frequencies, whether an app or OS
asks "is TSC safe" or not.

Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>