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>, "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: Mon, 20 Jul 2009 13:02:40 -0700 (PDT)
Cc: Ian Pratt <Ian.Pratt@xxxxxxxxxxxxx>, "Dong, Eddie" <eddie.dong@xxxxxxxxx>, "Zhang, Xiantao" <xiantao.zhang@xxxxxxxxx>, John Levon <levon@xxxxxxxxxxxxxxxxx>
Delivery-date: Mon, 20 Jul 2009 13:03:18 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <C68A6496.FF3A%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
> > The default mode for all xen systems should be that all rdtsc
> > instructions should be emulated by xen using xen system time
> > as the timestamp counter (i.e. nanosecond frequency).
> > 
> > The no-softtsc Xen boot option remains available to force the
> > non-trapping mechanism if desired.  It might make sense to
> > add a per-guest config option to override per guest.
> > 
> > The Xen CPU info emulation should reflect that tsc is constant
> > and safe to use on an SMP.
> > 
> > Comments?  I think someone at Intel (Eddie?) was studying the
> > TSC emulation path to see if it could be faster, but I'm not
> > sure where that ended up.
> Defaults which slow things down are never popular. The slowdown on a
> non-idle Solaris guest, for example, could be significant. It is a
> correctness/accuracy vs performance tradeoff though. But I 
> don't think there
> are many real-world complaints about the TSC accuracy now -- 
> I think the
> default is set appropriately.

Just wondering... are there other known cases in Xen where
a correctness-vs-performance tradeoff has been made in favor
of performance?

I agree that if the performance is *really bad*, the default
should not change.  But I think we are still flying on rumors
of data collected years ago in a very different world, and
the performance data should be re-collected to prove that
it is still *really bad*.  If the degradation is a fraction
of a percent even in worst case analysis, I think the default
should be changed so that correctness prevails.

Why now?  Because more and more real-world applications are
built on top of multi-core platforms where TSC is reliable
and (by far) the best timesource.  And I think(?) we all agree
now that softtsc is the only way to guarantee correctness
in a virtual environment.

Xen-devel mailing list