Re: [Xen-devel] [PATCH] Always save/restore performance counters when HVM guest switching VCPU

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 08.03.13 at 15:56, George Dunlap <george.dunlap@xxxxxxxxxxxxx> wrote:
> On 08/03/13 14:50, Boris Ostrovsky wrote:
>> ----- JBeulich@xxxxxxxx wrote:
>>
>>>>>> On 04.03.13 at 13:42, George Dunlap <George.Dunlap@xxxxxxxxxxxxx>
>>> wrote:
>>>> On Fri, Mar 1, 2013 at 8:49 PM,  <suravee.suthikulpanit@xxxxxxx>
>>> wrote:
>>>>> From: Suravee Suthikulpanit <suravee.suthikulpanit@xxxxxxx>
>>>>>
>>>>> Currently, the performance counter registers are saved/restores
>>>>> when the HVM guest switchs VCPUs only if they are running.
>>>>> However, PERF has one check where it writes the MSR and read back
>>>>> the value to check if the MSR is working.  This has shown to fails
>>>>> the check if the VCPU is moved in between rdmsr and wrmsr and
>>>>> resulting in the values are different.
>>>> Many moons ago (circa 2005) when I used performance counters, I
>>> found
>>>> that adding them to the save/restore path added a non-neligible
>>>> overhead -- something like 5% slow-down.  Do you have any reason to
>>>> believe this is no longer the case?  Have you done any benchmarks
>>>> before and after?
>> I was doing some VPMU tracing a couple of weeks ago and by looking at
>> trace timestamps I think I saw about 4000 cycles on VPMU save and
>> ~9000 cycles on restore. Don't remember what it was percentage-wise of
>> a whole context switch.
>>
>> This was on Intel.
> 
> That's a really hefty expense to make all users pay on every context 
> switch, on behalf of a random check in a piece of software that only a 
> handful of people are going to be actually using.
> 
> I'm having a hard time telling what PERF is being talked about here -- 
> couldn't this check be fixed on their side, by perhaps checking the 
> CPUID leaf for the existence of Xen?
> 
> If not I think a "lazy vpmu activation" is going to be the only option.

Fully agree.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel