lkml.org 
[lkml]   [2012]   [Jan]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: perf: prctl(PR_TASK_PERF_EVENTS_DISABLE) has no effect
From
Date
On Mon, 2012-01-30 at 12:31 +0100, Ingo Molnar wrote:
> * Peter Zijlstra <a.p.zijlstra@chello.nl> wrote:
>
> > On Mon, 2012-01-30 at 11:11 +0100, Ingo Molnar wrote:
> > > So, what workflow are you suggesting to Andrew?
> >
> > Librarize perf record, then in your code do something like:
> >
> > #include "perf_record.h"
>
> Maybe. (and then it shouldnt be limited to perf_record.h but
> should be events.h plus libevents.so or such)

Yes it should be, you want to reserve the more generic name for less
narrow interfaces.

> >
> > handle = perf_record_init(); /* creates perf events and creates
> > a record thread that writes samples
> > to perf.data, consumes env(PERF_*)
> > for configuration, registers with
> > at_exit() for cleanup */
> > if (!handle)
> > /* burn */
> >
> > /* do you other code */
> >
> > perf_record_start(handle);
> >
> > /* do the bit you want profiled */
> >
> > perf_record_stop(handle);
> >
> > Then build with -lperfrecord or so. Not too hard, right?
>
> Isnt a simple prctl() so much easier and faster?

I really don't want to add another two prctl()s for this, ideally I'd
remove the ones we have now, but I've never done due to maintaining
backwards blah..

> What's your concern with the prctl()? This would arguably be the
> right kind of usage for prctl(): it's an established API/ABI for
> process/task-wide settings.

Its doing things backwards, also the whole concept of allowing people to
hide things from a profiler is so rotten I'm not willing to even
consider the notion.


\
 
 \ /
  Last update: 2012-01-30 14:47    [W:0.051 / U:3.172 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site