Messages in this thread | | | Date | Mon, 2 Nov 2009 21:47:49 +1100 | From | Paul Mackerras <> | Subject | Re: [PATCH 1/6] perf/core: Provide a kernel-internal interface to get to performance counters |
| |
Arjan van de Ven writes:
> On Mon, 2 Nov 2009 14:46:55 +1100 > Paul Mackerras <paulus@samba.org> wrote: > > > Frederic Weisbecker writes: > > > > > /* > > > + * perf_event_create_kernel_counter > > > + * MUST be called from a kernel thread. > > > > Why? The reason for this requirement isn't obvious to me. It would > > be good to have the reason documented in the comment for the sake of > > people modifying the code in future. > > because if you call it from another context it will attach to that > context... and go away when that context goes away...
I don't think that's right. When a task exits, that doesn't automatically kill all the perf_events it created. The perf_events each have a reference to their owner's task_struct, so the task_struct will hang around until all of the perf_events get released. Normally top-level perf_events have an associated filp and we use its reference count to control the perf_event lifetime, but with these new kernel perf_events there is no filp, so the caller will have to do any refcounting required.
Bottom line is that a perf_event created by perf_event_create_kernel_counter will exist until someone calls perf_event_release_kernel on it, whether or not the owner task exits (and whether or not that task is a kernel thread or a usermode process). So I see no need to prohibit creating kernel perf_events in the context of a user task, though callers need to be aware that doing so could potentially mean the user task's task_struct has to hang around for a long time after the task exits.
Paul.
| |