From: Namhyung Kim <namhyung@kernel.org>
To: Arnaldo Carvalho de Melo <acme@kernel.org>
Cc: "Adrian Hunter" <adrian.hunter@intel.com>,
"Borislav Petkov" <bp@suse.de>, "David Ahern" <dsahern@gmail.com>,
"Frederic Weisbecker" <fweisbec@gmail.com>,
"Jiri Olsa" <jolsa@redhat.com>,
"Stephane Eranian" <eranian@google.com>,
"Wang Nan" <wangnan0@huawei.com>,
"Ingo Molnar" <mingo@kernel.org>,
"平松雅巳 / HIRAMATU,MASAMI" <masami.hiramatsu.pt@hitachi.com>,
"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH/RFC] perf buildid: Cache kernel DSO created when reading buildid header table
Date: Fri, 25 Sep 2015 14:54:52 +0900 [thread overview]
Message-ID: <20150925055452.GA13862@sejong> (raw)
In-Reply-To: <20150924155631.GK1897@kernel.org>
On Thu, Sep 24, 2015 at 12:56:31PM -0300, Arnaldo Carvalho de Melo wrote:
> Em Fri, Sep 25, 2015 at 12:01:12AM +0900, Namhyung Kim escreveu:
> > Hi Arnaldo,
> >
> > On Thu, Sep 24, 2015 at 10:42:28AM -0300, Arnaldo Carvalho de Melo wrote:
> > > Namhyung,
> > >
> > > Can you take a look and perhaps give me your Acked-by?
> >
> > The dso->kernel and event->cpumode is always confusing for modules..
>
> Right, my idea is to delete dso->kernel, to remove this confusion.
I'm fine with that. :)
>
> Please see my tmp.perf/core branch, there are a few patches there using
> alternative methods in places previously using the botched dso->kernel.
>
> > In this case, it seems that mmap events set kernel cpumode but
> > build-id events don't.
>
> in the previous sentence you think build-id events don't set
> perf_event_attr.misc bits related to cpumode...
>
> > So kernel cpumode in a bulid-id event
> > indicates that it is a kernel (vmlinux) dso, right?
>
> While here you ask if it does?
I mean that cpumode is not set for modules, so if you see cpumode set,
it should be the kernel dso..
>
> All these are synthesized, it is a matter of looking at the routines
> synthesizing them :-)
Right.
>
> > I'll test this tomorrow..
>
> Thanks, over time there were areas where multiple people touched and
> added different semantics that are biting now, I'm trying to, while
> fixing a bug, the one Wang Nan reported, clarify those things.
>
> It is taking more time than I antecipated, as I'm stumbling in what look
> like other bugs in the perf-probe codebase :-/
OK, after applying this patch, perf cannot find vmlinux anymore. It
finds scsi_mod.ko.gz instead, resulting in no kernel symbols..
Before:
$ perf report | grep -F '[k]' | head
0.44% cc1 [kernel.vmlinux] [k] clear_page_c
0.34% cc1 [kernel.vmlinux] [k] page_fault
0.22% cc1 [kernel.vmlinux] [k] get_page_from_freelist
0.22% cc1 [kernel.vmlinux] [k] handle_mm_fault
0.15% cc1 [kernel.vmlinux] [k] __do_page_fault
0.13% cc1 [kernel.vmlinux] [k] unmap_single_vma
0.12% cc1 [kernel.vmlinux] [k] __mem_cgroup_count_vm_event
0.11% cc1 [kernel.vmlinux] [k] mem_cgroup_try_charge
0.11% cc1 [kernel.vmlinux] [k] __d_lookup_rcu
0.11% cc1 [kernel.vmlinux] [k] copy_user_generic_string
After: (same data file but having no symbol affects the result)
$ perf report | grep -F '[k]' | head
0.42% cc1 scsi_mod.ko.gz [k] 0xffffffff812b4077
0.33% cc1 scsi_mod.ko.gz [k] 0xffffffff8153f9d0
0.11% cc1 scsi_mod.ko.gz [k] 0xffffffff8117ec0c
0.10% cc1 scsi_mod.ko.gz [k] 0xffffffff812b443c
0.10% as scsi_mod.ko.gz [k] 0xffffffff812b4077
0.08% cc1 scsi_mod.ko.gz [k] 0xffffffff811bbd90
0.07% cc1 scsi_mod.ko.gz [k] 0xffffffff811bf188
0.07% as scsi_mod.ko.gz [k] 0xffffffff8153f9d0
0.06% sh scsi_mod.ko.gz [k] 0xffffffff8153f9d0
0.06% cc1 scsi_mod.ko.gz [k] 0xffffffff811e0838
Unfortunately, I don't have to time to look at it now. It's one of
the biggest national holiday in Korea so maybe I can have a look later
in next week.
Thanks,
Namhyung
next prev parent reply other threads:[~2015-09-25 6:08 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-24 13:42 [PATCH/RFC] perf buildid: Cache kernel DSO created when reading buildid header table Arnaldo Carvalho de Melo
2015-09-24 15:01 ` Namhyung Kim
2015-09-24 15:56 ` Arnaldo Carvalho de Melo
2015-09-25 5:54 ` Namhyung Kim [this message]
2015-09-25 12:49 ` Arnaldo Carvalho de Melo
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=20150925055452.GA13862@sejong \
--to=namhyung@kernel.org \
--cc=acme@kernel.org \
--cc=adrian.hunter@intel.com \
--cc=bp@suse.de \
--cc=dsahern@gmail.com \
--cc=eranian@google.com \
--cc=fweisbec@gmail.com \
--cc=jolsa@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=masami.hiramatsu.pt@hitachi.com \
--cc=mingo@kernel.org \
--cc=wangnan0@huawei.com \
/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