Message-Id: <1269314081.2078.63.camel@ymzhang.sh.intel.com>
Date:	Tue, 23 Mar 2010 11:14:41 +0800
From:	"Zhang, Yanmin" <yanmin_zhang@...ux.intel.com>
To:	Arnaldo Carvalho de Melo <acme@...hat.com>
Cc:	Ingo Molnar <mingo@...e.hu>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Avi Kivity <avi@...hat.com>,
	Sheng Yang <sheng@...ux.intel.com>,
	linux-kernel@...r.kernel.org, kvm@...r.kernel.org,
	Marcelo Tosatti <mtosatti@...hat.com>,
	oerg Roedel <joro@...tes.org>,
	Jes Sorensen <Jes.Sorensen@...hat.com>,
	Gleb Natapov <gleb@...hat.com>,
	Zachary Amsden <zamsden@...hat.com>, zhiteng.huang@...el.com,
	Frédéric Weisbecker <fweisbec@...il.com>
Subject: Re: [PATCH] Enhance perf to collect KVM guest os statistics from
 host side

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@...pio linux-2.6-tip]$ l /sys/kernel/notes 
> -r--r--r-- 1 root root 36 2010-03-22 13:14 /sys/kernel/notes
> [acme@...pio 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@...pio 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


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists