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

[Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>]

> > 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
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel