From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeremy Fitzhardinge Subject: Re: Re: Live migration fails due to c/s 20627 Date: Wed, 16 Dec 2009 09:31:19 -0800 Message-ID: <4B291967.6060602@goop.org> References: <2d3fc836-b2af-4e5f-95b8-407283927f04@default> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <2d3fc836-b2af-4e5f-95b8-407283927f04@default> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Dan Magenheimer Cc: xen-devel@lists.xensource.com, kurt.hackel@oracle.com, "Dugger, Donald D" , "Xu, Dongxiao" , Keir Fraser , "Nakajima, Jun" , "Zhang, Xiantao" List-Id: xen-devel@lists.xenproject.org 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. J