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


Re: [Xen-devel] Re: Live migration fails due to c/s 20627

To: Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>
Subject: Re: [Xen-devel] Re: Live migration fails due to c/s 20627
From: Jeremy Fitzhardinge <jeremy@xxxxxxxx>
Date: Wed, 16 Dec 2009 09:31:19 -0800
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, kurt.hackel@xxxxxxxxxx, "Dugger, Donald D" <donald.d.dugger@xxxxxxxxx>, "Xu, Dongxiao" <dongxiao.xu@xxxxxxxxx>, Keir Fraser <keir.fraser@xxxxxxxxxxxxx>, "Nakajima, Jun" <jun.nakajima@xxxxxxxxx>, "Zhang, Xiantao" <xiantao.zhang@xxxxxxxxx>
Delivery-date: Wed, 16 Dec 2009 09:31:43 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <2d3fc836-b2af-4e5f-95b8-407283927f04@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>
References: <2d3fc836-b2af-4e5f-95b8-407283927f04@default>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20091203 Fedora/3.0-3.13.rc2.fc12 Thunderbird/3.0
On 12/16/2009 07:20 AM, Dan Magenheimer wrote:
Well, "heuristic" implies a reasonably high probability of
getting the right answer.  Would you agree that the probability
that TSC_AUX gets the "right" answer is much higher
in a physical environment than in a (non-pinned) virtual
environment?  And if the heuristic is wrong more often
than right, that using that heuristic is a bad idea?

It won't make a difference either way. Running in a Xen domain, the kernel will only see a single NUMA node, so the node id is constant. The CPU number may not correspond to a pcpu all the time, but scheduler affinity should make a given vcpu number correspond to the same pcpu for a while.

In either case, an application paying attention to cpu+node will do at least as well as an app ignoring them. So I don't think your argument that "if TSC_AUX cannot ALWAYS be trusted by an application, apps will NEVER trust it" is true at all.

Aside from the fact that the cpu+node issue is completely irrelevant to whether we support TSC_AUX.


Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>