[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <50399556C9727B4D88A595C8584AAB37526515DD@GSjpTKYDCembx32.service.hitachi.net>
Date: Fri, 11 Dec 2015 02:08:18 +0000
From: 平松雅巳 / HIRAMATU,MASAMI
<masami.hiramatsu.pt@...achi.com>
To: "'Wangnan (F)'" <wangnan0@...wei.com>,
"'Arnaldo Carvalho de Melo'" <acme@...nel.org>
CC: Peter Zijlstra <a.p.zijlstra@...llo.nl>,
Adrian Hunter <adrian.hunter@...el.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-perf-users@...r.kernel.org" <linux-perf-users@...r.kernel.org>,
Ingo Molnar <mingo@...hat.com>,
"Namhyung Kim" <namhyung@...nel.org>, Jiri Olsa <jolsa@...hat.com>,
Alexei Starovoitov <ast@...mgrid.com>
Subject: RE: [PATCH perf/core 00/22] perf refcnt debugger API and fixes
From: Wangnan (F) [mailto:wangnan0@...wei.com]
>On 2015/12/10 23:12, 'Arnaldo Carvalho de Melo' wrote:
>
>[SNIP]
>> But this requires having these special refcnt__ routines, that will make
>> tools/perf/ code patterns for reference counts look different that the
>> refcount patterns in the kernel :-\
>>
>> And would be a requirement to change the observed workload :-\
>>
>> Is this _strictly_ required?
>
>No. The requirement should be:
>
> 1. The create/get/put/delete functions are non-inline (because dwarf info
> is not as reliable as symbol);
> 2. From their argument list, we can always get the variable we need (the
> pointer of objects, the value of refcnt, etc.)
However, we have to customize it for each application. Perf itself might be OK
but others might have different implementation.
Thanks,
Powered by blists - more mailing lists