[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



----- 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 believe Linux uses perf infrastructure to implement the watchdog.

> 
> 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 by "here" you refer to the problem that Suravee's patch is trying to
address then I suspect it's this:
  http://lxr.linux.no/#linux+v3.8.2/arch/x86/kernel/cpu/perf_event.c#L210

> 
> If not I think a "lazy vpmu activation" is going to be the only
> option.

Yes, I actually was going to look at that.

-boris

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.