lkml.org 
[lkml]   [2010]   [Mar]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [PATCH] Enhance perf to collect KVM guest os statistics from host side
    From
    Date
    On Mon, 2010-03-22 at 13:44 -0300, Arnaldo Carvalho de Melo wrote:
    > Em Mon, Mar 22, 2010 at 03:24:47PM +0800, Zhang, Yanmin escreveu:
    > > On Fri, 2010-03-19 at 09:21 +0100, Ingo Molnar wrote:
    > > > So some sort of --guestmount option would be the natural solution, which
    > > > points to the guest system's root: and a Qemu enumeration of guest mounts
    > > > (which would be off by default and configurable) from which perf can pick up
    > > > the target guest all automatically. (obviously only under allowed permissions
    > > > so that such access is secure)
    > > If sshfs could access /proc/ and /sys correctly, here is a design:
    > > --guestmount points to a directory which consists of a list of sub-directories.
    > > Every sub-directory's name is just the qemu process id of guest os. Admin/developer
    > > mounts every guest os instance's root directory to corresponding sub-directory.
    > >
    > > Then, perf could access all files. It's possible because guest os instance
    > > happens to be multi-threading in a process. One of the defects is the accessing to
    > > guest os becomes slow or impossible when guest os is very busy.
    >
    > If the MMAP events on the guest included a cookie that could later be
    > used to query for the symtab of that DSO, we wouldn't need to access the
    > guest FS at all, right?
    It depends on specific sub commands. As for 'perf kvm top', developers want to see
    the profiling immediately. Even with 'perf kvm record', developers also want to
    see results quickly. At least I'm eager for the results when investigating
    a performance issue.

    >
    > With build-ids and debuginfo-install like tools the symbol resolution
    > could be performed by using the cookies (build-ids) as keys to get to
    > the *-debuginfo packages with matching symtabs (and DWARF for source
    > annotation, etc).
    We can't make sure guest os uses the same os images, or don't know where we
    could find the original DVD images being used to install guest os.

    Current perf does save build id, including both kernls's and other application
    lib/executables.

    >
    > We have that for the kernel as:
    >
    > [acme@doppio linux-2.6-tip]$ l /sys/kernel/notes
    > -r--r--r-- 1 root root 36 2010-03-22 13:14 /sys/kernel/notes
    > [acme@doppio linux-2.6-tip]$ l /sys/module/ipv6/sections/.note.gnu.build-id
    > -r--r--r-- 1 root root 4096 2010-03-22 13:38 /sys/module/ipv6/sections/.note.gnu.build-id
    > [acme@doppio linux-2.6-tip]$
    >
    > That way we would cover DSOs being reinstalled in long running 'perf
    > record' sessions too.
    That's one of objectives of perf to support long running.

    >
    > This was discussed some time ago but would require help from the bits
    > that load DSOs.
    >
    > build-ids then would be first class citizens.
    >
    > - Arnaldo




    \
     
     \ /
      Last update: 2010-03-23 04:17    [W:2.589 / U:0.120 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site