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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.