On Thu, 2010-03-04 at 09:00 +0800, Zhang, Yanmin wrote:
> On Wed, 2010-03-03 at 11:15 +0100, Peter Zijlstra wrote:
> > On Wed, 2010-03-03 at 17:27 +0800, Zhang, Yanmin wrote:
> > > -#ifndef perf_misc_flags
> > > -#define perf_misc_flags(regs) (user_mode(regs) ? PERF_RECORD_MISC_USER
> > > : \
> >
On 02/26/2010 04:42 PM, Peter Zijlstra wrote:
Also, intel debugstore things requires a host linear address,
It requires a linear address, not a host linear address. Of course, it
might not like the linear address mappings changing under its feet. If
it has a private tlb, then this won't wo
On 03/01/2010 07:17 PM, Peter Zijlstra wrote:
2. For every emulated performance counter the guest activates kvm
allocates a perf_event and configures it for the guest (we may allow
kvm to specify the counter index, the guest would be able to use
rdpmc unintercepted then). Event fil
On Wed, 2010-03-03 at 11:15 +0100, Peter Zijlstra wrote:
> On Wed, 2010-03-03 at 17:27 +0800, Zhang, Yanmin wrote:
> > -#ifndef perf_misc_flags
> > -#define perf_misc_flags(regs) (user_mode(regs) ? PERF_RECORD_MISC_USER : \
> > -PERF_RECORD_MISC_KERNEL)
> > -#define
On Wed, 2010-03-03 at 11:13 +0100, Peter Zijlstra wrote:
> On Wed, 2010-03-03 at 17:27 +0800, Zhang, Yanmin wrote:
> > +static inline u64 perf_instruction_pointer(struct pt_regs *regs)
> > +{
> > + u64 ip;
> > + ip = percpu_read(perf_virt_ip.ip);
> > + if (!ip)
> > +
On Wed, 2010-03-03 at 17:27 +0800, Zhang, Yanmin wrote:
> -#ifndef perf_misc_flags
> -#define perf_misc_flags(regs) (user_mode(regs) ? PERF_RECORD_MISC_USER : \
> -PERF_RECORD_MISC_KERNEL)
> -#define perf_instruction_pointer(regs) instruction_pointer(regs)
> -#endif
On Wed, 2010-03-03 at 17:27 +0800, Zhang, Yanmin wrote:
> +static inline u64 perf_instruction_pointer(struct pt_regs *regs)
> +{
> + u64 ip;
> + ip = percpu_read(perf_virt_ip.ip);
> + if (!ip)
> + ip = instruction_pointer(regs);
> + else
> + perf_
On Wed, 2010-03-03 at 11:32 +0800, Zhang, Yanmin wrote:
> On Tue, 2010-03-02 at 10:36 +0100, Ingo Molnar wrote:
> > * Zhang, Yanmin wrote:
> >
> > > On Fri, 2010-02-26 at 10:17 +0100, Ingo Molnar wrote:
> >
> > > > My suggestion, as always, would be to start very simple and very
> > > > minimal
On Tue, 2010-03-02 at 10:36 +0100, Ingo Molnar wrote:
> * Zhang, Yanmin wrote:
>
> > On Fri, 2010-02-26 at 10:17 +0100, Ingo Molnar wrote:
>
> > > My suggestion, as always, would be to start very simple and very minimal:
> > >
> > > Enable 'perf kvm top' to show guest overhead. Use the exact sa
On Tue, 2010-03-02 at 15:09 +0800, Zhang, Yanmin wrote:
> With vanilla host kernel, perf top data is stable and spinlock doesn't take
> too much cpu time.
> With guest os, __ticket_spin_lock consumes 28% cpu time, and sometimes it
> fluctuates between 9%~28%.
>
> Another interesting finding is a
* Zhang, Yanmin wrote:
> On Fri, 2010-02-26 at 10:17 +0100, Ingo Molnar wrote:
> > My suggestion, as always, would be to start very simple and very minimal:
> >
> > Enable 'perf kvm top' to show guest overhead. Use the exact same kernel
> > image both as a host and as guest (for testing), to
On Fri, 2010-02-26 at 10:17 +0100, Ingo Molnar wrote:
> * Joerg Roedel wrote:
>
> > On Fri, Feb 26, 2010 at 10:55:17AM +0800, Zhang, Yanmin wrote:
> > > On Thu, 2010-02-25 at 18:34 +0100, Joerg Roedel wrote:
> > > > On Thu, Feb 25, 2010 at 04:04:28PM +0100, Jes Sorensen wrote:
> > > >
> > > > >
On 02/26/2010 05:55 AM, Peter Zijlstra wrote:
On Fri, 2010-02-26 at 17:11 +0200, Avi Kivity wrote:
On 02/26/2010 05:08 PM, Peter Zijlstra wrote:
That's 7 more than what we support now, and 7 more than what we can
guarantee without it.
Again, what windows software uses only
On 02/26/2010 03:37 AM, Jes Sorensen wrote:
On 02/26/10 14:31, Ingo Molnar wrote:
You are missing two big things wrt. compatibility here:
1) The first upgrade overhead a one time overhead only.
2) Once a Linux guest has upgraded, it will work in the future,
with _any_
future CPU - _
On Mon, Mar 01, 2010 at 06:17:40PM +0100, Peter Zijlstra wrote:
> On Mon, 2010-03-01 at 12:11 +0100, Joerg Roedel wrote:
> >
> > 1. Enhance perf to count pmu events only when cpu is in guest mode.
>
> No enhancements needed, only hardware support for Intel doesn't provide
> this iirc.
At least t
On Mon, 2010-03-01 at 12:11 +0100, Joerg Roedel wrote:
>
> 1. Enhance perf to count pmu events only when cpu is in guest mode.
No enhancements needed, only hardware support for Intel doesn't provide
this iirc.
> 2. For every emulated performance counter the guest activates kvm
>allocates a p
On 02/26/2010 01:42 AM, Ingo Molnar wrote:
* Jes Sorensen wrote:
On 02/26/10 11:44, Ingo Molnar wrote:
Direct access to counters is not something that is a big issue. [ Given that i
sometimes can see KVM redraw the screen of a guest OS real-time i doubt this
is the biggest of perfor
On Mon, Mar 01, 2010 at 09:44:50AM +0100, Ingo Molnar wrote:
> There's a world of a difference between "will not use in certain usecases"
> and
> "cannot use at all because we've designed it so". By doing the latter we
> guarantee that sane shared usage of the PMU will never occur - which is ba
* Joerg Roedel wrote:
> On Mon, Mar 01, 2010 at 09:39:04AM +0100, Ingo Molnar wrote:
> > > What do you mean by software events?
> >
> > Things like:
> >
> > aldebaran:~> perf stat -a sleep 1
> >
> > Performance counter stats for 'sleep 1':
> >
> >15995.719133 task-clock-msecs #
On Mon, Mar 01, 2010 at 09:39:04AM +0100, Ingo Molnar wrote:
> > What do you mean by software events?
>
> Things like:
>
> aldebaran:~> perf stat -a sleep 1
>
> Performance counter stats for 'sleep 1':
>
>15995.719133 task-clock-msecs # 15.981 CPUs
>5787 context-
* Joerg Roedel wrote:
> On Fri, Feb 26, 2010 at 02:44:00PM +0100, Ingo Molnar wrote:
> > - A paravirt event driver is more compatible and more transparent in the
> > long
> >run: it allows hardware upgrade and upgraded PMU functionality (for
> > Linux)
> >without having to upgrade t
* Joerg Roedel wrote:
> > - It's more secure: the host can have a finegrained policy about what
> > kinds of
> >events it exposes to the guest. It might chose to only expose software
> >events for example.
>
> What do you mean by software events?
Things like:
aldebaran:~> perf stat
On Fri, Feb 26, 2010 at 04:14:08PM +0100, Peter Zijlstra wrote:
> On Fri, 2010-02-26 at 16:53 +0200, Avi Kivity wrote:
> > > If you give a full PMU to a guest it's a whole different dimension and
> > > quality
> > > of information. Literally hundreds of different events about all sorts of
> > > as
On Fri, Feb 26, 2010 at 03:12:29PM +0100, Ingo Molnar wrote:
> You mean Windows?
>
> For heaven's sake, why dont you think like Linus thought 20 years ago. To the
> hell with Windows suckiness and lets make sure our stuff works well. Then the
> users will come, developers will come, and people w
On Fri, Feb 26, 2010 at 02:44:00PM +0100, Ingo Molnar wrote:
> - A paravirt event driver is more compatible and more transparent in the
> long
>run: it allows hardware upgrade and upgraded PMU functionality (for Linux)
>without having to upgrade the guest OS. Via that a guest OS could e
On 02/26/2010 06:03 PM, Avi Kivity wrote:
Note, I'll be away for a week, so will not be responsive for a while
--
Do not meddle in the internals of kernels, for they are subtle and quick to
panic.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to maj
On 02/26/2010 05:55 PM, Peter Zijlstra wrote:
BTW, just wondering, why would a developer be running VTune in a guest
anyway? I'd think that a developer that windows oriented would simply
run windows on his desktop and VTune there.
Cloud.
You have an app running somewhere on a cloud, intern
On 02/26/2010 04:37 PM, Ingo Molnar wrote:
* Avi Kivity wrote:
Certainly guests that we don't port won't be able to use this. I doubt
we'll be able to make Windows work with this - the only performance tool I'm
familiar with on Windows is Intel's VTune, and that's proprietary.
On Fri, 2010-02-26 at 17:11 +0200, Avi Kivity wrote:
> On 02/26/2010 05:08 PM, Peter Zijlstra wrote:
> >> That's 7 more than what we support now, and 7 more than what we can
> >> guarantee without it.
> >>
> > Again, what windows software uses only those 7? Does it pay to only have
> > access
On Fri, 2010-02-26 at 17:11 +0200, Avi Kivity wrote:
> On 02/26/2010 05:08 PM, Peter Zijlstra wrote:
> >> That's 7 more than what we support now, and 7 more than what we can
> >> guarantee without it.
> >>
> > Again, what windows software uses only those 7? Does it pay to only have
> > access
On Fri, 2010-02-26 at 16:53 +0200, Avi Kivity wrote:
> > If you give a full PMU to a guest it's a whole different dimension and
> > quality
> > of information. Literally hundreds of different events about all sorts of
> > aspects of the CPU and the hardware in general.
> >
>
> Well, we filter
On 02/26/2010 05:08 PM, Peter Zijlstra wrote:
That's 7 more than what we support now, and 7 more than what we can
guarantee without it.
Again, what windows software uses only those 7? Does it pay to only have
access to those 7 or does it limit the usability to exactly the same
subset a par
On Fri, 2010-02-26 at 16:54 +0200, Avi Kivity wrote:
> On 02/26/2010 04:27 PM, Peter Zijlstra wrote:
> > On Fri, 2010-02-26 at 15:55 +0200, Avi Kivity wrote:
> >
> >> That actually works on the Intel-only architectural pmu. I'm beginning
> >> to like it more and more.
> >>
> > Only for t
On 02/26/2010 04:27 PM, Peter Zijlstra wrote:
On Fri, 2010-02-26 at 15:55 +0200, Avi Kivity wrote:
That actually works on the Intel-only architectural pmu. I'm beginning
to like it more and more.
Only for the arch defined events, all _7_ of them.
That's 7 more than what we supp
On 02/26/2010 04:12 PM, Ingo Molnar wrote:
Again you are making an incorrect assumption: that information leakage via the
PMU only occurs while the host is running on that CPU. It does not - the PMU
can leak general system details _while the guest is running_.
You mean like bus transact
On Fri, 2010-02-26 at 15:30 +0200, Avi Kivity wrote:
>
> Scheduling at event granularity would be a good thing. However we need
> to be able to handle the guest using the full pmu.
Does the full PMU include things like LBR, PEBS and uncore? in that
case, there is no way you're going to get tha
On Fri, 2010-02-26 at 15:30 +0200, Avi Kivity wrote:
>
> Even if there were no security considerations, if the guest can observe
> host data in the pmu, it means the pmu is inaccurate. We should expose
> guest data only in the guest pmu. That's not difficult to do, you stop
> the pmu on exit
On Fri, 2010-02-26 at 14:51 +0100, Jes Sorensen wrote:
>
> > Furthermore, when KVM doesn't virtualize the physical system topology,
> > some PMU features cannot even be sanely used from a vcpu.
>
> That is definitely an issue, and there is nothing we can really do about
> that. Having two guests
* Avi Kivity wrote:
> >> Certainly guests that we don't port won't be able to use this. I doubt
> >> we'll be able to make Windows work with this - the only performance tool
> >> I'm
> >> familiar with on Windows is Intel's VTune, and that's proprietary.
> >
> > Dont you see the extreme irony
On Fri, 2010-02-26 at 15:55 +0200, Avi Kivity wrote:
>
> That actually works on the Intel-only architectural pmu. I'm beginning
> to like it more and more.
Only for the arch defined events, all _7_ of them.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a mes
On 02/26/2010 04:01 PM, Ingo Molnar wrote:
* Avi Kivity wrote:
On 02/26/2010 03:31 PM, Ingo Molnar wrote:
* Avi Kivity wrote:
Or do you mean to define a new, kvm-specific pmu model and feed it off the
host pmu? In this case all the guests will need to be taught about it
* Avi Kivity wrote:
> On 02/26/2010 03:44 PM, Ingo Molnar wrote:
> >* Avi Kivity wrote:
> >
> >>On 02/26/2010 03:06 PM, Ingo Molnar wrote:
> >Firstly, an emulated PMU was only the second-tier option i suggested. By
> >far
> >the best approach is native API to the host regarding per
On 02/26/2010 04:07 PM, Jes Sorensen wrote:
On 02/26/10 14:27, Ingo Molnar wrote:
* Jes Sorensen wrote:
You certainly cannot emulate the Core2 on a P4. The Core2 is Perfmon
v2,
whereas Nehalem and Atom are v3 if I remember correctly. [...]
Of course you can emulate a good portion of it, as
On 02/26/10 14:27, Ingo Molnar wrote:
* Jes Sorensen wrote:
You certainly cannot emulate the Core2 on a P4. The Core2 is Perfmon v2,
whereas Nehalem and Atom are v3 if I remember correctly. [...]
Of course you can emulate a good portion of it, as long as there's perf
support on the host side
* Avi Kivity wrote:
> On 02/26/2010 03:31 PM, Ingo Molnar wrote:
> >* Avi Kivity wrote:
> >
> >>Or do you mean to define a new, kvm-specific pmu model and feed it off the
> >>host pmu? In this case all the guests will need to be taught about it,
> >>which raises the compatibility problem.
> >Y
On 02/26/2010 03:37 PM, Jes Sorensen wrote:
On 02/26/10 14:31, Ingo Molnar wrote:
You are missing two big things wrt. compatibility here:
1) The first upgrade overhead a one time overhead only.
2) Once a Linux guest has upgraded, it will work in the future,
with _any_
future CPU - _
On 02/26/2010 03:44 PM, Ingo Molnar wrote:
* Avi Kivity wrote:
On 02/26/2010 03:06 PM, Ingo Molnar wrote:
Firstly, an emulated PMU was only the second-tier option i suggested. By far
the best approach is native API to the host regarding performance events and
good guest side
On 02/26/10 14:28, Peter Zijlstra wrote:
On Fri, 2010-02-26 at 13:51 +0200, Avi Kivity wrote:
It would be the other way round - the host would steal the pmu from the
guest. Later we can try to time-slice and extrapolate, though that's
not going to be easy.
Right, so perf already does the tim
On 02/26/2010 03:28 PM, Peter Zijlstra wrote:
On Fri, 2010-02-26 at 13:51 +0200, Avi Kivity wrote:
It would be the other way round - the host would steal the pmu from the
guest. Later we can try to time-slice and extrapolate, though that's
not going to be easy.
Right, so perf alread
* Avi Kivity wrote:
> On 02/26/2010 03:06 PM, Ingo Molnar wrote:
> >
> >>>Firstly, an emulated PMU was only the second-tier option i suggested. By
> >>>far
> >>>the best approach is native API to the host regarding performance events
> >>>and
> >>>good guest side integration.
> >>>
> >>>Second
On 02/26/2010 03:31 PM, Ingo Molnar wrote:
* Avi Kivity wrote:
Or do you mean to define a new, kvm-specific pmu model and feed it off the
host pmu? In this case all the guests will need to be taught about it,
which raises the compatibility problem.
You are missing two big things wr
On 02/26/10 14:31, Ingo Molnar wrote:
You are missing two big things wrt. compatibility here:
1) The first upgrade overhead a one time overhead only.
2) Once a Linux guest has upgraded, it will work in the future, with _any_
future CPU - _without_ having to upgrade the guest!
Dont you
On 02/26/10 14:18, Ingo Molnar wrote:
* Avi Kivity wrote:
Can you emulate the Core 2 pmu on, say, a P4? [...]
How about the Pentium? Or the i486?
As long as there's perf events support, the CPU can be supported in a soft
PMU. You can even cross-map exotic hw events if need to be - but most
On Fri, 2010-02-26 at 13:51 +0200, Avi Kivity wrote:
> It would be the other way round - the host would steal the pmu from the
> guest. Later we can try to time-slice and extrapolate, though that's
> not going to be easy.
Right, so perf already does the time slicing and interpolating thing, s
On 02/26/10 14:30, Avi Kivity wrote:
On 02/26/2010 03:06 PM, Ingo Molnar wrote:
That's precisely my point: the guest should obviously not get raw
access to
the PMU. (except where it might matter to performance, such as RDPMC)
That's doable if all counters are steerable. IIRC some counters are
On 02/26/2010 03:27 PM, Ingo Molnar wrote:
For Linux<->Linux the sanest, tier-1 approach would be to map sys_perf_open()
on the guest side over to the host, transparently, via a paravirt driver.
Let us for the purpose of this discussion assume that we are also
interested in supporting Win
* Avi Kivity wrote:
> Or do you mean to define a new, kvm-specific pmu model and feed it off the
> host pmu? In this case all the guests will need to be taught about it,
> which raises the compatibility problem.
You are missing two big things wrt. compatibility here:
1) The first upgrade o
On 02/26/10 14:06, Ingo Molnar wrote:
* Jes Sorensen wrote:
Well you cannot steal the PMU without collaborating with perf_event.c, but
thats quite feasible. Sharing the PMU between the guest and the host is very
costly and guarantees incorrect results in the host. Unless you completely
emulate
On 02/26/2010 03:06 PM, Ingo Molnar wrote:
Firstly, an emulated PMU was only the second-tier option i suggested. By far
the best approach is native API to the host regarding performance events and
good guest side integration.
Secondly, the PMU cannot be 'given' to the guest in the general case
* Jes Sorensen wrote:
> > Agree about favouring modern processors.
>
> You certainly cannot emulate the Core2 on a P4. The Core2 is Perfmon v2,
> whereas Nehalem and Atom are v3 if I remember correctly. [...]
Of course you can emulate a good portion of it, as long as there's perf
support on
* Avi Kivity wrote:
> Can you emulate the Core 2 pmu on, say, a P4? [...]
How about the Pentium? Or the i486?
As long as there's perf events support, the CPU can be supported in a soft
PMU. You can even cross-map exotic hw events if need to be - but most of the
tooling (in just about any OS)
On 02/26/10 14:04, Avi Kivity wrote:
On 02/26/2010 02:38 PM, Ingo Molnar wrote:
Yes, something like Core2 with 2 generic events.
That would leave 2 extra generic events on Nehalem and better. (which is
really the target CPU type for any new feature we are talking about
right now.
Plus performan
* Jes Sorensen wrote:
> On 02/26/10 12:42, Ingo Molnar wrote:
> >
> >* Jes Sorensen wrote:
> >>
> >> I have to say I disagree on that. When you run perfmon on a system, it is
> >> normally to measure a specific application. You want to see accurate
> >> numbers for cache misses, mul instructi
On 02/26/2010 02:38 PM, Ingo Molnar wrote:
* Avi Kivity wrote:
On 02/26/2010 02:07 PM, Ingo Molnar wrote:
* Avi Kivity wrote:
A native API to the host will lock out 100% of the install base now, and a
large section of any future install base.
... which is why
On 02/26/10 13:20, Avi Kivity wrote:
On 02/26/2010 02:07 PM, Ingo Molnar wrote:
... which is why i suggested the soft-PMU approach.
Not sure I understand it completely.
Do you mean to take the model specific host pmu events, and expose them
to the guest via trap'n'emulate? In that case we may
On 02/26/10 12:42, Ingo Molnar wrote:
* Jes Sorensen wrote:
I have to say I disagree on that. When you run perfmon on a system, it is
normally to measure a specific application. You want to see accurate numbers
for cache misses, mul instructions or whatever else is selected.
You can still ge
* Avi Kivity wrote:
> On 02/26/2010 02:07 PM, Ingo Molnar wrote:
> >* Avi Kivity wrote:
> >
> >>A native API to the host will lock out 100% of the install base now, and a
> >>large section of any future install base.
> >... which is why i suggested the soft-PMU approach.
>
> Not sure I underst
On 02/26/2010 02:07 PM, Ingo Molnar wrote:
* Avi Kivity wrote:
A native API to the host will lock out 100% of the install base now, and a
large section of any future install base.
... which is why i suggested the soft-PMU approach.
Not sure I understand it completely.
Do you
* Avi Kivity wrote:
> A native API to the host will lock out 100% of the install base now, and a
> large section of any future install base.
... which is why i suggested the soft-PMU approach.
And note that _any_ solution we offer locks out 100% of the installed base
right now, as no solutio
On 02/26/2010 01:42 PM, Ingo Molnar wrote:
* Jes Sorensen wrote:
On 02/26/10 11:44, Ingo Molnar wrote:
Direct access to counters is not something that is a big issue. [ Given that i
sometimes can see KVM redraw the screen of a guest OS real-time i doubt this
is the biggest of perfor
On 02/26/2010 01:26 PM, Ingo Molnar wrote:
By far the biggest instrumentation issue is:
- availability
- usability
- flexibility
Exposing the raw hw is a step backwards in many regards.
In a way, virtualization as a whole is a step backwards. We take the nice
firesystem/timer/
* Jes Sorensen wrote:
> On 02/26/10 11:44, Ingo Molnar wrote:
> >Direct access to counters is not something that is a big issue. [ Given that
> >i
> >sometimes can see KVM redraw the screen of a guest OS real-time i doubt this
> >is the biggest of performance challenges right now ;-) ]
> >
> >B
* Avi Kivity wrote:
> On 02/26/2010 12:44 PM, Ingo Molnar wrote:
> >>>Far cleaner would be to expose it via hypercalls to guest OSs that are
> >>>interested in instrumentation.
> >>It's also slower - you can give the guest direct access to the various
> >>counters so no exits are taken when read
On 02/26/10 12:24, Ingo Molnar wrote:
There is a way to query the CPU for 'architectural perfmon' though, via CPUID
alone - that is how we set the X86_FEATURE_ARCH_PERFMON shortcut. The logic
is:
if (c->cpuid_level> 9) {
unsigned eax = cpuid_eax(10);
/
* Jes Sorensen wrote:
> On 02/26/10 12:06, Joerg Roedel wrote:
>
> > Isn't there a cpuid bit indicating the availability of architectural
> > perfmon?
>
> Nope, the perfmon flag is a fake Linux flag, set based on the contents on
> cpuid 0x0a
There is a way to query the CPU for 'architectural
On 02/26/10 11:44, Ingo Molnar wrote:
Direct access to counters is not something that is a big issue. [ Given that i
sometimes can see KVM redraw the screen of a guest OS real-time i doubt this
is the biggest of performance challenges right now ;-) ]
By far the biggest instrumentation issue is:
* Joerg Roedel wrote:
> On Fri, Feb 26, 2010 at 11:46:59AM +0100, Ingo Molnar wrote:
> >
> > * Joerg Roedel wrote:
> >
> > > On Fri, Feb 26, 2010 at 11:46:34AM +0200, Avi Kivity wrote:
> > > > On 02/26/2010 10:42 AM, Ingo Molnar wrote:
> > > >> Note that the 'soft PMU' still sucks from a desi
On 02/26/10 12:06, Joerg Roedel wrote:
Isn't there a cpuid bit indicating the availability of architectural
perfmon?
Nope, the perfmon flag is a fake Linux flag, set based on the contents
on cpuid 0x0a
Jes
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a mess
On 02/26/2010 12:44 PM, Ingo Molnar wrote:
Far cleaner would be to expose it via hypercalls to guest OSs that are
interested in instrumentation.
It's also slower - you can give the guest direct access to the various
counters so no exits are taken when reading the counters (though perhaps
On Fri, Feb 26, 2010 at 11:46:59AM +0100, Ingo Molnar wrote:
>
> * Joerg Roedel wrote:
>
> > On Fri, Feb 26, 2010 at 11:46:34AM +0200, Avi Kivity wrote:
> > > On 02/26/2010 10:42 AM, Ingo Molnar wrote:
> > >> Note that the 'soft PMU' still sucks from a design POV as there's no
> > >> generic
>
On 02/25/10 18:34, Joerg Roedel wrote:
The biggest problem I see here is teaching the guest about the available
events. The available event sets are dependent on the processor family
(at least on AMD).
A simple approach would be shadowing the perf msrs which is a simple
thing to do. More problema
On 02/25/10 17:26, Ingo Molnar wrote:
Given that perf can apply the PMU to individual host tasks, I don't see
fundamental problems multiplexing it between individual guests (which can
then internally multiplex it again).
In terms of how to expose it to guests, a 'soft PMU' might be a usable
app
* Joerg Roedel wrote:
> On Fri, Feb 26, 2010 at 10:17:32AM +0100, Ingo Molnar wrote:
> > My suggestion, as always, would be to start very simple and very minimal:
> >
> > Enable 'perf kvm top' to show guest overhead. Use the exact same kernel
> > image
> > both as a host and as guest (for tes
On 02/26/2010 12:46 PM, Ingo Molnar wrote:
Right, this will severely limit migration domains to hosts of the same
vendor and processor generation. There is a middle ground, though,
Intel has recently moved to define an "architectural pmu" which is not
model specific. I don't know if AMD adop
* Joerg Roedel wrote:
> On Fri, Feb 26, 2010 at 11:46:34AM +0200, Avi Kivity wrote:
> > On 02/26/2010 10:42 AM, Ingo Molnar wrote:
> >> Note that the 'soft PMU' still sucks from a design POV as there's no
> >> generic
> >> hw interface to the PMU. So there would have to be a 'soft AMD' and a 's
* Avi Kivity wrote:
> Right, this will severely limit migration domains to hosts of the same
> vendor and processor generation. There is a middle ground, though, Intel
> has recently moved to define an "architectural pmu" which is not model
> specific. I don't know if AMD adopted it. [...]
On Fri, Feb 26, 2010 at 10:17:32AM +0100, Ingo Molnar wrote:
> My suggestion, as always, would be to start very simple and very minimal:
>
> Enable 'perf kvm top' to show guest overhead. Use the exact same kernel image
> both as a host and as guest (for testing), to not have to deal with the
> s
On Fri, Feb 26, 2010 at 11:46:34AM +0200, Avi Kivity wrote:
> On 02/26/2010 10:42 AM, Ingo Molnar wrote:
>> Note that the 'soft PMU' still sucks from a design POV as there's no generic
>> hw interface to the PMU. So there would have to be a 'soft AMD' and a 'soft
>> Intel' PMU driver at minimum.
>>
On 02/26/2010 10:42 AM, Ingo Molnar wrote:
* Joerg Roedel wrote:
I personally don't like a self-defined event-set as the only solution
because that would probably only work with linux and perf. [...]
The 'soft-PMU' i suggested is transparent on the guest side - if you want to
enable
* Joerg Roedel wrote:
> On Fri, Feb 26, 2010 at 10:55:17AM +0800, Zhang, Yanmin wrote:
> > On Thu, 2010-02-25 at 18:34 +0100, Joerg Roedel wrote:
> > > On Thu, Feb 25, 2010 at 04:04:28PM +0100, Jes Sorensen wrote:
> > >
> > > > 1) Add support to perf to allow it to monitor a KVM guest from the
On Fri, Feb 26, 2010 at 10:55:17AM +0800, Zhang, Yanmin wrote:
> On Thu, 2010-02-25 at 18:34 +0100, Joerg Roedel wrote:
> > On Thu, Feb 25, 2010 at 04:04:28PM +0100, Jes Sorensen wrote:
> >
> > > 1) Add support to perf to allow it to monitor a KVM guest from the
> > >host.
> >
> > This should
* Zhang, Yanmin wrote:
> On Thu, 2010-02-25 at 17:26 +0100, Ingo Molnar wrote:
> > * Jan Kiszka wrote:
> >
> > > Jes Sorensen wrote:
> > > > Hi,
> > > >
> > > > It looks like several of us have been looking at how to use the PMU
> > > > for virtualization. Rather than continuing to have discu
* Joerg Roedel wrote:
> I personally don't like a self-defined event-set as the only solution
> because that would probably only work with linux and perf. [...]
The 'soft-PMU' i suggested is transparent on the guest side - if you want to
enable non-Linux and legacy-Linux.
It's basically a PM
On Thu, 2010-02-25 at 18:34 +0100, Joerg Roedel wrote:
> On Thu, Feb 25, 2010 at 04:04:28PM +0100, Jes Sorensen wrote:
>
> > 1) Add support to perf to allow it to monitor a KVM guest from the
> >host.
>
> This shouldn't be a big problem. The PMU of AMD Fam10 processors can be
> configured to
On Thu, 2010-02-25 at 17:26 +0100, Ingo Molnar wrote:
> * Jan Kiszka wrote:
>
> > Jes Sorensen wrote:
> > > Hi,
> > >
> > > It looks like several of us have been looking at how to use the PMU
> > > for virtualization. Rather than continuing to have discussions in
> > > smaller groups, I think it
* Jan Kiszka wrote:
> Jes Sorensen wrote:
> > Hi,
> >
> > It looks like several of us have been looking at how to use the PMU
> > for virtualization. Rather than continuing to have discussions in
> > smaller groups, I think it is a good idea we move it to the mailing
> > lists to see what we ca
Jes Sorensen wrote:
> Hi,
>
> It looks like several of us have been looking at how to use the PMU
> for virtualization. Rather than continuing to have discussions in
> smaller groups, I think it is a good idea we move it to the mailing
> lists to see what we can share and avoid duplicate efforts.
Hi,
It looks like several of us have been looking at how to use the PMU
for virtualization. Rather than continuing to have discussions in
smaller groups, I think it is a good idea we move it to the mailing
lists to see what we can share and avoid duplicate efforts.
There are really two separate
98 matches
Mail list logo
