From: Stephane Eranian <email@example.com>
Cc: Arnaldo Carvalho de Melo <firstname.lastname@example.org>,
Avi Kivity <email@example.com>
Subject: Re: [PATCH] perf: fix broken perf inject -b
Date: Thu, 2 Feb 2012 12:22:36 +0100 [thread overview]
Message-ID: <CABPqkBRe76z9KwdqOoaT6JmMFFmadG3Ltck-8y+fY8qUCcECQA@mail.gmail.com> (raw)
On Tue, Jan 31, 2012 at 6:58 AM, Yanmin Zhang
> On Mon, 2012-01-30 at 18:36 -0200, Arnaldo Carvalho de Melo wrote:
>> Em Mon, Jan 30, 2012 at 09:09:17PM +0100, Stephane Eranian escreveu:
>> > On Mon, Jan 30, 2012 at 9:04 PM, Arnaldo Carvalho de Melo
>> > <firstname.lastname@example.org> wrote:
>> > > Em Mon, Jan 30, 2012 at 08:53:26PM +0100, Stephane Eranian escreveu:
>> > >> On Mon, Jan 30, 2012 at 8:00 PM, Arnaldo Carvalho de Melo
>> > >> <email@example.com> wrote:
>> > >> > > >>> @@ -173,6 +178,7 @@ static int perf_event__inject_buildid(struct perf_tool *tool,
>> > >> > > >>> goto repipe;
>> > >> > > >>> }
>> > >> > > >>> + machine->pid = event->ip.pid;
>> > >> >
>> > >> > > I noticed that this statement conflicts with perf buildid-list (which
>> > >> > > I am also fixing for pipe mode).
>> > >> > > I don't quite understand why, though.
>> > >> > Have you reached any conclusion about this problem? I haven't looked at
>> > >> > it in detail, could you please elaborate more?
>> > >> I ended up removing it. But I am not sure this is correct.
>> > >> Is the pid used in any way when processing buildids?
>> > >
>> > > I can't think of any.
>> > >
>> > > The same DSO could conceivably be present in the virtual machine, the
>> > > host, and in the workstation used for perf report. We just use the
>> > > build-id in the perf.data file to find the right symtab.
>> > Right, so I don't know why it's there...
>> This comes from a1645ce1:
>> commit a1645ce12adb6c9cc9e19d7695466204e3f017fe
>> Author: Zhang, Yanmin <firstname.lastname@example.org>
>> Date: Mon Apr 19 13:32:50 2010 +0800
>> perf: 'perf kvm' tool for monitoring guest performance from host
>> Here is the patch of userspace perf tool.
>> Signed-off-by: Zhang Yanmin <email@example.com>
>> Signed-off-by: Avi Kivity <firstname.lastname@example.org>
>> Zhang, what was the thinking about that pid in the buildid event?
> I didn't work on it for a long time because of some special reasons.
> I check it quickly and below are some explanation.
> machine->pid is to support KVM multiple guest os kernels.
> 1) The guest os kernels might be different version of kernels from host's;
> 2) The guest os might be Windows.
I understand that.
> At host side, every guest os is a process of host although it's multi-threaded.
> machine->pid is to save its pid. The pid of host itself is HOST_KERNEL_ID.
What do you mean by the 'pid of the host'? You always capture samples on the
host on behalf of a host task. I see PID:-1 to simulate mmap of the kernel in
the perf.data file. Is that what you are referring to?
> In guest os, there are many processes. host os doesn't know them. So currently or
> when I enhanced perf to support KVM, perf filters out guest os user space
> detailed event samples while still keeping guest os user space simple counters.
That is not clear to me. Are you saying, you have no visibility into
the guest OS
user space processes, samples captured at that level are attributed to
Or are you simply dropping them?
> event->ip.pid is equal to machine->pid only when
> ((event->header.misc & PERF_RECORD_MISC_CPUMODE_MASK) == PERF_RECORD_MISC_GUEST_KERNEL).
> In function perf_event__inject_buildid, we shouldn't reset machine->pid to
> event->ip.pid. They are equal to each other if it's a guest os event. Isn't it?
I have not tried capturing samples on a kvm process. So I don't know.
> If the event is host event, event->ip.pid points to a real process at host
> and it shouldn't be equal to machine->pid (HOST_KERNEL_ID).
next prev parent reply other threads:[~2012-02-02 11:22 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-13 14:47 [PATCH] perf: fix broken perf inject -b Stephane Eranian
2012-01-13 16:53 ` Arnaldo Carvalho de Melo
2012-01-13 16:54 ` Stephane Eranian
2012-01-16 18:53 ` Stephane Eranian
2012-01-30 19:00 ` Arnaldo Carvalho de Melo
2012-01-30 19:53 ` Stephane Eranian
2012-01-30 20:04 ` Arnaldo Carvalho de Melo
2012-01-30 20:09 ` Stephane Eranian
2012-01-30 20:36 ` Arnaldo Carvalho de Melo
2012-01-31 5:58 ` Yanmin Zhang
2012-02-02 11:22 ` Stephane Eranian [this message]
2012-02-03 3:30 ` Yanmin Zhang
2012-01-26 14:16 ` Stephane Eranian
2012-01-26 14:23 ` Arnaldo Carvalho de Melo
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:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* 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;
as well as URLs for NNTP newsgroup(s).