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] write_tsc in a PV domain?

To: Alan Cox <alan@xxxxxxxxxxxxxxxxxxx>
Subject: RE: [Xen-devel] write_tsc in a PV domain?
From: Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>
Date: Fri, 28 Aug 2009 08:16:21 -0700 (PDT)
Cc: Jeremy Fitzhardinge <jeremy@xxxxxxxx>, "Xen-Devel \(E-mail\)" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Delivery-date: Fri, 28 Aug 2009 08:17:01 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <20090828104915.56cf1002@xxxxxxxxxxxxxxxxxxx>
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
Hi Alan --

> > No, I don't think this is true.  An enterprise app that 
> binds processes
> > to fixed physical processors on a physical machine can make
> > assumptions about the results of rdtsc that aren't valid when
> > the vcpus can skip between pcpus.  Further, like Linux itself,
> They rarely make the right assumptions

I freely admit that there are a high percentage of
apps-that-use-rdtsc that are at risk of being buggy
if moved from a "tsc safe" machine to a "tsc unsafe"
machine.  But, echoing your earlier reply, there are
some that are careful and smart about using rdtsc.

Jeremy's claim is that because some apps-that-use-
rdtsc risk bugginess, Xen can claim rdtsc for its own
use and effectively disallow all uses of rdtsc in any
app by breaking the existing, sometimes-useful semantics
of the instruction.

> > True, but any app that tries to run on a NUMA machine without
> > being aware of the idiosyncracies of a NUMA machine probably
> > has worse problems to deal with than tsc sync.  Further, there
> Disagree - this is true if your NUMA factor is large but quite a few
> machines today are "vaguely NUMA" - the NUMA factor is low 
> enough the app
> doesn't need to care. Anyway you don't need NUMA to see TSC 
> skew between cores.

Yes, but I think we are agreeing here.  My point, poorly
made I admit, is that there are a lot of different machine
topologies and we can't force all applications to
conform to the lowest common denominator.

Xen-devel mailing list