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

[Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>]

> > 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

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