From mboxrd@z Thu Jan 1 00:00:00 1970 From: George Dunlap Subject: Re: [PATCH] Always save/restore performance counters when HVM guest switching VCPU Date: Fri, 8 Mar 2013 14:56:08 +0000 Message-ID: <5139FC08.8030907@eu.citrix.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Boris Ostrovsky Cc: "suravee.suthikulpanit@amd.com" , "JBeulich@suse.com" , "xen-devel@lists.xen.org" List-Id: xen-devel@lists.xenproject.org On 08/03/13 14:50, Boris Ostrovsky wrote: > ----- JBeulich@suse.com wrote: > >>>>> On 04.03.13 at 13:42, George Dunlap >> wrote: >>> On Fri, Mar 1, 2013 at 8:49 PM, >> wrote: >>>> From: Suravee Suthikulpanit >>>> >>>> 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. -George