| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] Proposal for Xen support of performance monitoring andde
Ian Pratt wrote:
Rik van Riel pointed me at the Santos's patch for oprofile support.
There are some differences between the two approaches. The
Xen oprofile
support by HP pretty much just supports oprofile and was
designed to get
some information about what was going on in the Xen hypervisor. It
doesn't provide access to the other performance monitoring (or
debugging) hardware.
The extended xen-oprofile is a useful tool for getting a global view of
what's going on in the whole machine.
I think what you're proposing is for enabling a guest to get a better
idea of what's going on while it is running, which is also useful.
You can't really mix the two modes of operation on the same system, at
least not in the general case.
Right, mixing the different modes at the same time is not going to work,
but it would be nice to make the mechanism flexible enough so that the
same mechanism can be both for local and system-wide profiling.
I can certainly see some merit in having fine grained access control
over MSRs, though for the case of perf counter registers I wander
whether we'd be better off with some higher-level interface?
I was aiming for minimal support low-level, trying to follow the
existing Xen approach of not coding too much knowledge about
the system
in Xen. Make the MSR registers visible and make sure that a guest OS
cannot clobber other guest OSs. The guests OS decide how to use the
performance monitoring hw. The hypervisor needs a list of which
registers are in which class, but the hypervisor doesn't need to know
the details of what the registers do.
It seems sensible to incorporate a simple mechanism for enabling
fine-grained access control to msr's, and also code to save/restore msr
values that have been changed when context switching between guests.
One issue for guests that are using this mechanism is that I don't
believe it's possible to selectively count events in ring 1 vs ring 0.
Hence it will also count events in Xen during hypercalls and interrupt
handling. In some cases this will be what's wanted, in others, not. I
guess we could slectively save/restore counter values when
entering/leaving Xen, but that's slow and ugly.
Yes, the selectivity is ring != 0 or ring ==0. There isn't the finer
grain to separate the guest OS from the normal user space.
A place that things might get odd if the domain-0 handles things on the
behalf of guest domain. The sampling in local mode would not cross
domains. Thus, a user guest domain might not know that it is having a
lot of overhead in domain-0. However, in these cases people are probably
better off doing system-wide sampling.
-Will
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home