|
[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
Am Montag 11 MÃrz 2013, 10:53:49 schrieb Konrad Rzeszutek Wilk:
> On Mon, Mar 11, 2013 at 11:11:02AM +0000, George Dunlap wrote:
> > On 08/03/13 15:11, Boris Ostrovsky wrote:
> > >----- 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.
>
> And by default it won't work as for Intel you need these flags:
>
> cpuid=['0xa:eax=0x07300403,ebx=0x00000004,ecx=0x00000000,edx=0x00000603' ]
This cpuid config variable should not be needed if your cpu is supported in
vmx_vpmu_initialise() where you added a lot of processors with your patch.
If not supported and you should see a message in the xen logs.
>
> What we get right now when booting PVHVM under Intel is:
>
> [ 0.160989] Performance Events: unsupported p6 CPU model 45 no PMU driver,
> software events only.
> [ 0.168098] NMI watchdog disabled (cpu0): hardware events not enabled
Did you add vpmu to the xen boot parameter list?
I installed opensuse-12.2 as a HVM guest with xen-unstable running and the
kernel
log says:
Mar 7 15:06:18 linux kernel: [ 0.183217] CPU0: Intel(R) Core(TM)2 Duo CPU
P8800 @ 2.66GHz stepping 0a
Mar 7 15:06:18 linux kernel: [ 0.183980] Performance Events: 4-deep LBR,
Core2 events, Intel PMU driver.
Mar 7 15:06:18 linux kernel: [ 0.189994] ... version: 2
Mar 7 15:06:18 linux kernel: [ 0.189997] ... bit width: 40
Mar 7 15:06:18 linux kernel: [ 0.190000] ... generic registers: 2
Mar 7 15:06:18 linux kernel: [ 0.190002] ... value mask:
000000ffffffffff
Mar 7 15:06:18 linux kernel: [ 0.190005] ... max period:
000000007fffffff
Mar 7 15:06:18 linux kernel: [ 0.190008] ... fixed-purpose events: 3
Mar 7 15:06:18 linux kernel: [ 0.190011] ... event mask:
0000000700000003
Mar 7 15:06:18 linux kernel: [ 0.198203] NMI watchdog: enabled, takes one
hw-pmu counter.
When I call perf:
# perf stat ls
acpid cups kdm.log mail.err news
wtmp zypper.log
alternatives.log faillog krb5 mail.info ntp
Xorg.0.log
boot.log firewall lastlog mail.warn pm-powersave.log
Xorg.0.log.old
btmp hp localmessages messages samba
YaST2
ConsoleKit journal mail NetworkManager warn
zypp
Performance counter stats for 'ls':
7.840869 task-clock # 0.590 CPUs utilized
59 context-switches # 0.008 M/sec
0 CPU-migrations # 0.000 K/sec
304 page-faults # 0.039 M/sec
6,583,834 cycles # 0.840 GHz
[40.38%]
<not supported> stalled-cycles-frontend
<not supported> stalled-cycles-backend
2,168,931 instructions # 0.33 insns per cycle
[73.20%]
525,628 branches # 67.037 M/sec
[79.06%]
27,138 branch-misses # 5.16% of all branches
[83.55%]
0.013283672 seconds time elapsed
As you can see performance counters are working for instructions, branches
and branch-misses.
When I call this command in the dom0 it's a bit different:
# perf stat ls
acpid journal messages wpa_supplicant.log
alternatives.log kdm.log NetworkManager wtmp
boot.log krb5 news xen
btmp lastlog ntp Xorg.0.log
ConsoleKit localmessages pk_backend_zypp Xorg.0.log.old
cups mail pk_backend_zypp-1 YaST2
faillog mail.err pm-powersave.log zypp
firewall mail.info samba zypper.log
hp mail.warn warn zypper.log-20130307.xz
Performance counter stats for 'ls':
6.959326 task-clock # 0.714 CPUs utilized
11 context-switches # 0.002 M/sec
0 CPU-migrations # 0.000 K/sec
304 page-faults # 0.044 M/sec
<not supported> cycles
<not supported> stalled-cycles-frontend
<not supported> stalled-cycles-backend
<not supported> instructions
<not supported> branches
<not supported> branch-misses
0.009746152 seconds time elapsed
This is because the hardware events are not supported in PV.
Dietmar.
> Unless said above CPUID flag is provided.
> >
> > Hmm -- well if it is the case that adding performance counters to
> > the vcpu context switch path will add a measurable overhead, then we
> > probably don't want them enabled for typical guests anyway. If
> > people are actually using the performance counters to measure
> > performance, that makes sense; but for watchdogs it seems like Xen
> > should be able to provide something that is useful for a watchdog
> > without the extra overhead of saving and restoring performance
> > counters.
> >
> > Konrad, any thoughts?
>
> The other thing is that there is an Xen watchdog. The one that Jan Beulich
> wrote which should also work under PVHVM:
>
> drivers/watchdog/xen_wdt.c
>
>
> >
> > -George
--
Company details: http://ts.fujitsu.com/imprint.html
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |