From mboxrd@z Thu Jan 1 00:00:00 1970 From: Suravee Suthikulanit Subject: Re: [PATCH] Always save/restore performance counters when HVM guest switching VCPU Date: Fri, 8 Mar 2013 16:52:21 -0600 Message-ID: <513A6BA5.2010807@amd.com> References: <1362170975-2884-1-git-send-email-suravee.suthikulpanit@amd.com> <5139B3B202000078000C4187@nat28.tlf.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <5139B3B202000078000C4187@nat28.tlf.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich Cc: George Dunlap , "xen-devel@lists.xen.org" List-Id: xen-devel@lists.xenproject.org On 3/8/2013 2:47 AM, Jan Beulich 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? >> >> If there is a performance slow-down, you may have to implement >> something like the "lazy FPU" save/restore, where you remove access to >> the VPMU MSRs to detect that the guest is accessing them. > Suravee, > > without addressing George's concerns, I don't think you can > expect the patch to be committed (the more that Boris, along > with his ack, also asked to adjust the description). > > Jan > > I understand that we don't want to introduce this overhead. Let me look into: 1. Measuring the overhead in this case. 2. Looking into the alternative approach (lazy save/restore) and get back to you all. Suravee