Re: perf: prctl(PR_TASK_PERF_EVENTS_DISABLE) has no effect

[Iegorov Oleg <oleg_iegorov@mentor.com>]

Le 2012-07-27 10:29, Peter Zijlstra a écrit :
> On Fri, 2012-07-27 at 10:18 +0200, Ingo Molnar wrote:
>> * Peter Zijlstra<a.p.zijlstra@chello.nl>  wrote:
>>
>>> On Fri, 2012-07-27 at 09:26 +0200, Ingo Molnar wrote:
>>>> Maybe someone on Cc: would be interested in implementing this
>>>> new perf events feature?
>>> Why would we go build new kernel interfaces because userspace
>>> is silly?
>> Because it's (much) easier to use the existing perf tools almost
>> as-is instead of librarizing your own.
>>
>> It would also allow other usecases, like self-profiling a
>> library and then profiling it within the context of a larger app
>> that you don't want to rebuild and which dynamically links this
>> library.
> Uhm.. why not? For the first use proper self profiling, for the second
> do a regular 3rd party profile.
>
>> It also allows system-wide profiling after you've modified a
>> library to self-profile, while your suggestion does not allow
>> that.
> But its no long self-profiling when some other process is involved. And
> system wide is definitely not self.
>
>>> It really isn't that hard to make userspace do what is needed,
>>> it just takes a bit of work.
>> Even if your suggested solution was available (it isn't), my
>> suggested approach is easier to use and covers more usecases.
>>
>> User-space expecting the kernel to provide usable and minimal
>> interfaces is not 'being silly'. It's the fundamental task of a
>> kernel to provide them.
> Bloating the interface for something that is already well possible is.
>
> I really don't see the problem, other than that people simply don't want
> to do work.
I totally agree with Ingo. The key words here are "much easier to use".

Moreover, in my use case, it would add a lot of complexity to rebuild 
the application each time a new performance event is added/removed from 
the event set (if I understood correctly Peter's approach).

Regards,
Oleg