RE: [Xen-devel] RE: Saving/Restoring IA32_TSC_AUX MSR

["Xu, Dongxiao" <dongxiao.xu@xxxxxxxxx>]

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. 

Thanks!
Dongxiao

> 
> 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
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel