Re: perf monitoring triggers Was: Re: [tip:perf/core] perf bench: Print both of prefaulted and no prefaulted results by default

[Hitoshi Mitake <mitake@dcl.info.waseda.ac.jp>]

On 2010年12月13日 22:12, Arnaldo Carvalho de Melo wrote:
> Em Mon, Dec 13, 2010 at 01:40:59PM +0100, Peter Zijlstra escreveu:
>> On Mon, 2010-12-13 at 10:38 -0200, Arnaldo Carvalho de Melo wrote:
>>> Em Mon, Dec 13, 2010 at 12:14:33PM +0100, Peter Zijlstra escreveu:
>>>> Sounds to me like you want something like a library with self-monitoring
>>>> stuff.
>
>>> Yeah, that could be a way, an LD_PRELOAD thingy that would intercept
>>> library calls, setup counters, start a monitoring thread, etc.
>
>>> To make it easier we could move the counter setup we have in record/top
>>> to a library, etc.
>>
>> Nah, I was more thinking of something along the lines of libPAPI and
>> libpfmon. A library that contains the needed building blocks for apps to
>> profile themselves.
>
> Ok, you mean for the case where you can modify the app, I was thinking
> about when you can't.
>
> In both cases its good to move the counter creation, etc routines from
> record/top to a lib, that then could be used in the way you mention, and
> in the way I mention too. Two different usecases :-)

Thanks for your comments, Arnaldo, Peter.

I implement basic feature of my proposal,
and found that communicating perf stat and benchmarking programs
via socket is really dirty. As you said, unified form,
interception for unmodified binary and library for modifiable binary,
will be ideal for fine grain monitoring.

But I believe that measuring performance of some sort of programs
like in kernel routines requires more fine grain perf stating,
so I'll seek the unified way.

Anyway, I'll send my proof of concept patch later.

Thanks,
         Hitoshi