On Wed, Mar 24, 2010 at 06:57:47AM +0200, Avi Kivity wrote:
On 03/23/2010 08:21 PM, Joerg Roedel wrote:For the KVM stack is doesn't matter where it is implemented. It is as
This enumeration is a very small and non-intrusive feature. Making itIt's easier (and safer and all the other boring bits) not to do it at
aware of namespaces is easy too.
all in the kernel.
easy in qemu or libvirt as in the kernel. I also don't see big risks. On
the perf side and for its users it is a lot easier to have this in the
kernel.
I for example always use plain qemu when running kvm guests and never
used libvirt. The only central entity I have here is the kvm kernel
modules. I don't want to start using it only to be able to use perf kvm.
Could be easily done using notifier chains already in the kernel.Who would be the consumer of such notifications? A 'perf kvm list' canSystem-wide monitoring needs to work equally well for guests started
live without I guess. If we need them later we can still add them.
before or after the monitor.
Probably implemented with much less than 100 lines of additional code.
Even disregarding that, if you introduce an API, people will startThere is nothing wrong with that. We only need to define what this API
using it and complaining if it's incomplete.
should be used for to prevent rank growth. It could be an
instrumentation-only API for example.
When measuring cache-misses any additional (and in this caseMy statement was not limited to enumeration, I should have been moreWhy? Also, the real cost would be accessing the filesystem, not copying
clear about that. The guest filesystem access-channel is another
affected part. The 'perf kvm top' command will access the guest
filesystem regularly and going over qemu would be more overhead here.
data over qemu.
unnecessary) copy-overhead result in less appropriate results.
This has nothing to do with a library. It is about entity and resourceProviding this in the KVM module directly also has the benefit that itOther userspaces can also provide this functionality, like they have to
would work out-of-the-box with different userspaces too. Or do we want
to limit 'perf kvm' to the libvirt-qemu-kvm software stack?
provide disk, network, and display emulation. The kernel is not a huge
library.
management which is what os kernels are about. The virtual machine is
the entity (similar to a process) and we want to add additional access
channels and names to it.