From: Arnaldo Carvalho de Melo <acme@infradead.org>
To: Ingo Molnar <mingo@elte.hu>
Cc: Li Zefan <lizf@cn.fujitsu.com>,
Pekka Enberg <penberg@cs.helsinki.fi>,
Frederic Weisbecker <fweisbec@gmail.com>,
Steven Rostedt <rostedt@goodmis.org>,
Peter Zijlstra <peterz@infradead.org>,
Eduard - Gabriel Munteanu <eduard.munteanu@linux360.ro>,
LKML <linux-kernel@vger.kernel.org>,
"linux-mm@kvack.org" <linux-mm@kvack.org>
Subject: Re: [RFC][PATCH 1/2] perf: Add 'perf kmem' tool
Date: Fri, 20 Nov 2009 12:42:15 -0200 [thread overview]
Message-ID: <20091120144215.GH18283@ghostprotocols.net> (raw)
In-Reply-To: <20091120090353.GE19778@elte.hu>
Em Fri, Nov 20, 2009 at 10:03:53AM +0100, Ingo Molnar escreveu:
>
> * Li Zefan <lizf@cn.fujitsu.com> wrote:
>
> > > (2) doing "perf kmem record" on machine A (think embedded here) and
> > > then "perf kmem report" on machine B. I haven't tried kmemtrace-user
> > > for a while but it did support both of them quite nicely at some
> > > point.
> >
> > Everything needed and machine-specific will be recorded in perf.data,
> > so this should already been supported. I'll try it.
>
> Right now the DSOs are not recorded in the perf.data - but it would be
> useful to add it and to turn perf.data into a self-sufficient capture of
> all relevant data, which can be analyzed on any box.
Well, the DSOs are recorded in perf.data, just not its symtabs, but now
we have buildids, so we can ask for them to be installed on the other
machine and it'll all work. Or should. :)
For instance:
[root@doppio linux-2.6-tip]# perf buildid-list -i perf.data | egrep 'vmlinux|nfs|libc-'
ec8dd400904ddfcac8b1c343263a790f977159dc /lib64/libc-2.10.1.so
0da49504693a200583fda6f1b949e6d2f799e692 /usr/lib64/libnfsidmap_nsswitch.so.0.0.0
c90269c87eaf08559012a9fa29f60780743360cd /usr/lib64/libnfsidmap.so.0.3.0
18e7cc53db62a7d35e9d6f6c9ddc23017d38ee9a vmlinux
3982866276471cde6ac5821fdced42a7b1bfd848 [nfs]
1489007276a50005753e730198fd93dd05b2082f [nfsd]
5a128f082fe7fdcab6fb5d1b71935accb1f34383 [nfs_acl]
[root@doppio linux-2.6-tip]#
Now if I ask that the buildid for /usr/lib64/libnfsidmap.so.0.3.0 above
to be installed, like this:
[root@doppio linux-2.6-tip]# yum install /usr/lib/debug/.build-id/c9/0269c87eaf08559012a9fa29f60780743360cd
Loaded plugins: auto-update-debuginfo, refresh-packagekit
Found 44 installed debuginfo package(s)
Enabling fedora-debuginfo: Fedora 11 - x86_64 - Debug
Reading repository metadata in from local files
Enabling updates-debuginfo: Fedora 11 - x86_64 - Updates - Debug
Reading repository metadata in from local files
Setting up Install Process
Importing additional filelist information
Resolving Dependencies
--> Running transaction check
---> Package nfs-utils-lib-debuginfo.x86_64 0:1.1.4-6.fc11 set to be updated
--> Finished Dependency Resolution
Dependencies Resolved
========================================================================
Package Arch Version Repository Size
========================================================================
Installing:
nfs-utils-lib-debuginfo x86_64 1.1.4-6.fc11 fedora-debuginfo 174 k
Transaction Summary
========================================================================
Install 1 Package(s)
Upgrade 0 Package(s)
Total download size: 174 k
Is this ok [y/N]:
So now we have:
1) 'perf record' records the build-ids into perf.data
2) 'perf buildid-list' list them, distro specific porcelain needed
to do the equivalent to the yum install above.
3) 'perf report' will only use the symtab in a file that has the matching
build-id, if a build-id is found in the perf.data header for a
particular DSO.
So we have a mechanism that is already present in several distros
(build-id), that is in the kernel build process since ~2.6.23, and that
avoids using mismatching DSOs when resolving symbols.
I'm working on some of these aspects, but most of the infrastructure is
alreadu in tip.
- Arnaldo
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2009-11-20 14:42 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-11-20 7:53 Li Zefan
2009-11-20 7:53 ` [PATCH 2/2] tracing: Remove kmemtrace tracer Li Zefan
2009-11-20 8:20 ` Pekka Enberg
2009-11-20 8:24 ` Li Zefan
2009-11-20 8:27 ` Pekka Enberg
2009-11-20 8:31 ` Li Zefan
2009-11-20 8:14 ` [RFC][PATCH 1/2] perf: Add 'perf kmem' tool Ingo Molnar
2009-11-20 8:19 ` Pekka Enberg
2009-11-20 8:30 ` Ingo Molnar
2009-11-20 8:47 ` Pekka Enberg
2009-11-20 8:53 ` Li Zefan
2009-11-20 9:03 ` Ingo Molnar
2009-11-20 9:14 ` Li Zefan
2009-11-20 14:42 ` Arnaldo Carvalho de Melo [this message]
2009-11-20 16:41 ` Ingo Molnar
2009-11-20 17:52 ` Arnaldo Carvalho de Melo
2009-11-23 6:51 ` Ingo Molnar
2009-11-23 7:22 ` Peter Zijlstra
2009-11-23 7:33 ` Ingo Molnar
2009-11-23 14:37 ` Arnaldo Carvalho de Melo
2009-11-23 14:32 ` Arnaldo Carvalho de Melo
2009-11-20 9:01 ` Ingo Molnar
2009-11-20 9:15 ` Pekka Enberg
2009-11-20 10:13 ` Ingo Molnar
2009-11-20 10:31 ` Pekka Enberg
2009-11-20 10:49 ` Ingo Molnar
2009-11-23 14:46 ` Steven Rostedt
2009-11-23 17:53 ` Ingo Molnar
2009-11-20 8:20 ` Li Zefan
2009-11-20 8:54 ` [tip:perf/core] " tip-bot for Li Zefan
2009-11-20 8:55 ` [RFC][PATCH 1/2] " Ingo Molnar
2009-11-20 9:11 ` Li Zefan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20091120144215.GH18283@ghostprotocols.net \
--to=acme@infradead.org \
--cc=eduard.munteanu@linux360.ro \
--cc=fweisbec@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lizf@cn.fujitsu.com \
--cc=mingo@elte.hu \
--cc=penberg@cs.helsinki.fi \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox