Re: [PATCH/RFC] perf buildid: Cache kernel DSO created when reading buildid header table

[Arnaldo Carvalho de Melo <acme@kernel.org>]

Em Fri, Sep 25, 2015 at 02:54:52PM +0900, Namhyung Kim escreveu:
> 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..

Thanks for checking, will reproduce and add a 'perf test' entry before
trying to continue the work in this patch...

- Arnaldo
 
> 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