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

["Nakajima, Jun" <jun.nakajima@xxxxxxxxx>]

Jeremy Fitzhardinge wrote on Fri, 11 Dec 2009 at 10:50:29:

> On 12/11/09 10:35, Dan Magenheimer wrote:
>>> However, the vcpu number is definitely useful to usermode
>>> apps, so they
>>> can get some idea how they're moved between (v)cpus.  I don't
>>> think it
>>> will matter to them that it isn't pcpu.
>>> 
>> My point is that an app running on native Linux can
>> safely assume that, if TSC_AUX==3 at time T1 and
>> TSC_AUX is still 3 at time T2,it is running
>> on the same processor and the same node at both T1
>> and T2.  In a virtual environment it cannot even
>> assume it is running on the same machine.
>> Further if the app sees that TSC_AUX==2 at time T3
>> and TSC_AUX==3 at time T4, on native Linux it
>> can safely assume that it is running on a different
>> processor.  While rarer, in a virtual environment,
>> this may also be a false assumption.
>> 
>> That's why I say the information is misleading.
>> 
>  Sure, but that info is, at best, of heuristic value, and won't cause
> any correctness problems if it is wrong.  The performance may suck, but
> that's part of the larger problem of running NUMA-aware code in a
> virtual environment.
> 
 
And to utilize various NUMA optimizations in the kernel/apps in the guest, we 
need "the virtual numa info bears some vague resemblance to the real topology" 
(from Jeremy's email) with the vcpus bound to the CPU/node.

I understand that enabling RDTSCP in HVM will disable the pvrdtscp algorithm if 
used by the kernel. One way is to mask off the feature in CPUID (by default). 
Then kernel won't use it. 

Jun
___
Intel Open Source Technology Center




_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel