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

[Keir Fraser <keir.fraser@xxxxxxxxxxxxx>]

On 20/07/2009 21:02, "Dan Magenheimer" <dan.magenheimer@xxxxxxxxxx> wrote:

> 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.

So how bad is the non-softtsc default mode anyway? Our default timer_mode
has guest TSCs track host TSC (plus a fixed per-vcpu offset that defaults to
having all vcpus of a domain aligned to vcpu0 boot = zero tsc).

Looking at the email thread you cited, all I see is someone from Intel
saying something about how their code to improve TSC consistency across
migration avoids RDTSC exiting where possible (which I do not see -- if the
TSC rates across the hosts do not match closely then RDTSC exiting is
enabled forever for that domain), and, most bizarrely, that their 'solution'
may have a tsc drift >10^5 cycles. Where did this huge number come from?
What solution is being talked about, and under what conditions might the
claim hold? Who knows!

I don't think we have really solid data on either the performance or the
accuracy side of the debate. And that means we don't have much to argue
over.

 -- Keir



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