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

To: Jeremy Fitzhardinge <jeremy@xxxxxxxx>
Subject: RE: [Xen-devel] write_tsc in a PV domain?
From: Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>
Date: Fri, 28 Aug 2009 10:49:08 -0700 (PDT)
Cc: "Xen-Devel \(E-mail\)" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Keir Fraser <keir.fraser@xxxxxxxxxxxxx>, Alan Cox <alan@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Fri, 28 Aug 2009 12:51:08 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4A980D8D.1060708@xxxxxxxx>
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
> I think this is getting a bit repetitive.

True, and we are going down some unfortunate
ratholes.  So let's see if we can focus on
the core of the disagreement.

> Apps are free to try and use the tsc in any way they
> feel like, but it has never had any
> GUARANTEED [djm's emphasis] properties.

I think this is the key difference of opinion which
must be resolved.  If what you say is true, your
other positions make sense.  If it is false,
they make much less sense.  (And unfortunately
it is not a black and white issue.)

There ARE guaranteed properties specified by
the Intel SDM for any _single_ processor,
namely that rdtsc is "guaranteed to return
a monotonically increasing unique value whenever
executed, except for 64-bit counter wraparound.
Intel guarantees that the time-stamp counter
will not wrap-around within 10 years after being
reset."  Both uses of the word "guarantee"
are quoted from the Intel SDM.

What is NOT guaranteed, but is widely and
incorrectly assumed to be implied and has
gotten us into this mess, is that
the same properties applies across multiple
processors.  And there are notable examples
of systems where the properties do NOT apply.
So it is true that an app that
does not know conclusively that certain threads
are running on certain processors cannot
always safely use rdtsc to obtain the
single-processor-guaranteed results.

BUT some software systems (including VMware) do
provide this guarantee across multiple processors.
And recent families of both Intel and AMD
multi-core have advanced to the point where
the properties apply across all cores, so
on the vast majority (but admittedly not all)
of future physical systems, apps can and will
use rdtsc and expect the properties to apply
(whether guaranteed or not).

So in your opinion, some systems are broken
so Xen should assume all future systems are
broken.  In my opinion, the problem is being
fixed in hardware and has always been fixed
in VMware, so Xen should look to the future
not the past.

Does that sound like a good summary of this
disagreement?

P.S. Summarizing the broader discussion on a
new thread.

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