Enhance perf to collect KVM guest os statistics from host side
in [Kernel]
|
Prev: + tmpfs-fix-oops-on-remounts-with-mpol=default.patch added to -mm tree
Next: [PATCH 5/5] doc: add the documentation for mpol=local
From: Ingo Molnar on 16 Mar 2010 06:30 * Avi Kivity <avi(a)redhat.com> wrote: > On 03/16/2010 11:53 AM, Ingo Molnar wrote: > >* Avi Kivity<avi(a)redhat.com> wrote: > > > >>On 03/16/2010 09:24 AM, Ingo Molnar wrote: > >>>* Avi Kivity<avi(a)redhat.com> wrote: > >>> > >>>>On 03/16/2010 07:27 AM, Zhang, Yanmin wrote: > >>>>>From: Zhang, Yanmin<yanmin_zhang(a)linux.intel.com> > >>>>> > >>>>>Based on the discussion in KVM community, I worked out the patch to support > >>>>>perf to collect guest os statistics from host side. This patch is implemented > >>>>>with Ingo, Peter and some other guys' kind help. Yang Sheng pointed out a > >>>>>critical bug and provided good suggestions with other guys. I really appreciate > >>>>>their kind help. > >>>>> > >>>>>The patch adds new subcommand kvm to perf. > >>>>> > >>>>> perf kvm top > >>>>> perf kvm record > >>>>> perf kvm report > >>>>> perf kvm diff > >>>>> > >>>>>The new perf could profile guest os kernel except guest os user space, but it > >>>>>could summarize guest os user space utilization per guest os. > >>>>> > >>>>>Below are some examples. > >>>>>1) perf kvm top > >>>>>[root(a)lkp-ne01 norm]# perf kvm --host --guest --guestkallsyms=/home/ymzhang/guest/kallsyms > >>>>>--guestmodules=/home/ymzhang/guest/modules top > >>>>> > >>>>Excellent, support for guest kernel != host kernel is critical (I > >>>>can't remember the last time I ran same kernels). > >>>> > >>>>How would we support multiple guests with different kernels? Perhaps a > >>>>symbol server that perf can connect to (and that would connect to guests in > >>>>turn)? > >>>The highest quality solution would be if KVM offered a 'guest extension' to > >>>the guest kernel's /proc/kallsyms that made it easy for user-space to get this > >>>information from an authorative source. > >>> > >>>That's the main reason why the host side /proc/kallsyms is so popular and so > >>>useful: while in theory it's mostly redundant information which can be gleaned > >>>from the System.map and other sources of symbol information, it's easily > >>>available and is _always_ trustable to come from the host kernel. > >>> > >>>Separate System.map's have a tendency to go out of sync (or go missing when a > >>>devel kernel gets rebuilt, or if a devel package is not installed), and server > >>>ports (be that a TCP port space server or an UDP port space mount-point) are > >>>both a configuration hassle and are not guest-transparent. > >>> > >>>So for instrumentation infrastructure (such as perf) we have a large and well > >>>founded preference for intrinsic, built-in, kernel-provided information: i.e. > >>>a largely 'built-in' and transparent mechanism to get to guest symbols. > >>The symbol server's client can certainly access the bits through vmchannel. > >Ok, that would work i suspect. > > > >Would be nice to have the symbol server in tools/perf/ and also make it easy > >to add it to the initrd via a .config switch or so. > > > >That would have basically all of the advantages of being built into the kernel > >(availability, configurability, transparency, hackability), while having all > >the advantages of a user-space approach as well (flexibility, extensibility, > >robustness, ease of maintenance, etc.). > > Note, I am not advocating building the vmchannel client into the host > kernel. [...] Neither am i. What i suggested was a user-space binary/executable built in tools/perf and put into the initrd. That approach has the advantages i listed above, without having the disadvantages of in-kernel code you listed. Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Avi Kivity on 16 Mar 2010 06:50 On 03/16/2010 12:20 PM, Ingo Molnar wrote: >>>> >>>> The symbol server's client can certainly access the bits through vmchannel. >>>> >>> Ok, that would work i suspect. >>> >>> Would be nice to have the symbol server in tools/perf/ and also make it easy >>> to add it to the initrd via a .config switch or so. >>> >>> That would have basically all of the advantages of being built into the kernel >>> (availability, configurability, transparency, hackability), while having all >>> the advantages of a user-space approach as well (flexibility, extensibility, >>> robustness, ease of maintenance, etc.). >>> >> Note, I am not advocating building the vmchannel client into the host >> kernel. [...] >> > Neither am i. What i suggested was a user-space binary/executable built in > tools/perf and put into the initrd. > I'm confused - initrd seems to be guest-side. I was talking about the host side. For the guest, placing the symbol server in tools/ is reasonable. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Ingo Molnar on 16 Mar 2010 07:00 * Avi Kivity <avi(a)redhat.com> wrote: > On 03/16/2010 12:20 PM, Ingo Molnar wrote: > >>>> > >>>>The symbol server's client can certainly access the bits through vmchannel. > >>>Ok, that would work i suspect. > >>> > >>>Would be nice to have the symbol server in tools/perf/ and also make it easy > >>>to add it to the initrd via a .config switch or so. > >>> > >>>That would have basically all of the advantages of being built into the kernel > >>>(availability, configurability, transparency, hackability), while having all > >>>the advantages of a user-space approach as well (flexibility, extensibility, > >>>robustness, ease of maintenance, etc.). > >>Note, I am not advocating building the vmchannel client into the host > >>kernel. [...] > >Neither am i. What i suggested was a user-space binary/executable built in > >tools/perf and put into the initrd. > > I'm confused - initrd seems to be guest-side. I was talking about the host > side. host side doesnt need much support - just some client capability in perf itself. I suspect vmchannels are sufficiently flexible and configuration-free for such purposes? (i.e. like a filesystem in essence) Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Avi Kivity on 16 Mar 2010 07:20 On 03/16/2010 12:50 PM, Ingo Molnar wrote: > >> I'm confused - initrd seems to be guest-side. I was talking about the host >> side. >> > host side doesnt need much support - just some client capability in perf > itself. I suspect vmchannels are sufficiently flexible and configuration-free > for such purposes? (i.e. like a filesystem in essence) > I haven't followed vmchannel closely, but I think it is. vmchannel is terminated in qemu on the host side, not in the host kernel. So perf would need to connect to qemu. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Ingo Molnar on 16 Mar 2010 07:30
* Avi Kivity <avi(a)redhat.com> wrote: > On 03/16/2010 12:50 PM, Ingo Molnar wrote: > > > >>I'm confused - initrd seems to be guest-side. I was talking about the host > >>side. > >host side doesnt need much support - just some client capability in perf > >itself. I suspect vmchannels are sufficiently flexible and configuration-free > >for such purposes? (i.e. like a filesystem in essence) > > I haven't followed vmchannel closely, but I think it is. vmchannel is > terminated in qemu on the host side, not in the host kernel. So perf would > need to connect to qemu. Hm, that sounds rather messy if we want to use it to basically expose kernel functionality in a guest/host unified way. Is the qemu process discoverable in some secure way? Can we trust it? Is there some proper tooling available to do it, or do we have to push it through 2-3 packages to get such a useful feature done? ( That is the general thought process how many cross-discipline useful desktop/server features hit the bit bucket before having had any chance of being vetted by users, and why Linux sucks so much when it comes to feature integration and application usability. ) Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |