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: Saving/Restoring IA32_TSC_AUX MSR

To: Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>, "Nakajima, Jun" <jun.nakajima@xxxxxxxxx>, Jeremy Fitzhardinge <jeremy@xxxxxxxx>
Subject: RE: [Xen-devel] RE: Saving/Restoring IA32_TSC_AUX MSR
From: "Xu, Dongxiao" <dongxiao.xu@xxxxxxxxx>
Date: Sat, 12 Dec 2009 08:30:31 +0800
Accept-language: en-US
Acceptlanguage: en-US
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, "Dugger, Donald D" <donald.d.dugger@xxxxxxxxx>, Keir Fraser <keir.fraser@xxxxxxxxxxxxx>, "Zhang, Xiantao" <xiantao.zhang@xxxxxxxxx>
Delivery-date: Fri, 11 Dec 2009 16:30:52 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <186c235b-cc2e-41bc-a52a-76ef8a5c6fbe@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: <EADF0A36011179459010BDF5142A457501D13FE833@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <186c235b-cc2e-41bc-a52a-76ef8a5c6fbe@default>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Acp6v4m6+nuR2NCgRViDEer14kP+MgAAdXKw
Thread-topic: [Xen-devel] RE: Saving/Restoring IA32_TSC_AUX MSR
Dan Magenheimer wrote:
>>> Yes, it does.  If there were a reasonable way for an
>>> application to check "am I running on a VM for which
>>> each vcpu has been pinned?" this might be a reasonable
>>> constraint as, if the app isn't, it could fail or at least
>>> log a message.  But if the app will randomly fail
>>> (or perform horribly) depending on whether the
>>> underlying VM is pinned or not (which might even
>>> change across a migration or if a sysadmin is
>>> "tuning" his data center), I don't think
>>> enterprise customers would appreciate that.
>> Dan,
>>      If later guest NUMA is implemented, both APP and
>> Hypervisor/Guest are NUMA awared. APP could get benefit
>> From the information of node/processor which is got from
>> RDTSCP. But how to implement guest NUMA is another story,
>> either we can use pin, or something other creative idea.
> Right.  A guest NUMA implementation could use:
> 1) rdtscp+tsc_aux, which is very fast but unreliable
>    (unless the app can be certain the guest is permanently
>    pinned), or
> 2) some other yet-to-be-designed mechanism, likely involving
>    system calls and/or hypercalls, which is slower but can be
>    designed to be always reliable

Here is my simple understanding of guest NUMA: it means that
Hypervisor will present the correct NUMA information to 
Guest kernel/app. So once guest NUMA is implemented,
the information got from RDTSCP is both reliable and fast. 


> In my experience in the enterprise world, "slow but
> reliable" is always better than "fast but unreliable",
> except possibly in well-understood constrained situations.
> So I am suggesting we do not implement (1) by NOT
> enabling rdtscp-bit-in-cpuid and instead concentrate
> on (2).  I guess for the special cases where unreliable
> is acceptable, (1) could be an option, but I don't
> think it should be turned on by default.
> Dan
Xen-devel mailing list