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: Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>, "Xen-Devel (E-mail)" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: [Xen-devel] Re: TSC scaling and softtsc reprise, and PROPOSAL
From: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Date: Mon, 20 Jul 2009 22:02:50 +0100
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 14:03:24 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <37b05395-9936-4323-908b-b18c23f686a1@default>
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
Thread-index: AcoJdQ/DijOH8of9TL+OVpyH/VIdLQACGDwW
Thread-topic: TSC scaling and softtsc reprise, and PROPOSAL
User-agent: Microsoft-Entourage/
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

 -- Keir

Xen-devel mailing list