[lkml]   [2017]   [Oct]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RFC PATCH 05/17] perf: Introduce detached events
Peter Zijlstra <> writes:

> So I'm not opposed to the idea of creating events that live independent
> from of file descriptors. And stuffing them in a filesystem makes sense.
> However I'm not entire convinced on the details.
> The above has a number of problems:
> - there's a filesystem race; two concurrent syscalls can try and create
> the same file. In that case the error most certainly is not -ENOMEM.


> - there's a hash collision, similar issue.
> - there's some asymmetry in the create/destroy; that is you create the
> file with sys_perf_event_open() and remove it with unlink().

There is also an ioctl() to turn it into a normal event fd that can then
be closed.

> - the actual name is very opaque and hard to use; how would a tool find
> the right event to open?

They can readlink("/proc/self/fd/$fd"), something that I hacked into the
perf tool as well, although, truth be told I didn't actually need it for
anything, partly because it's not a useful name. One use case that I
could think of would be a task that's inherited a detached event wanting
to get rid of it. They can scan their /proc/$pid/maps, find the vma by
name and use that to locate the file.

> Would it instead make sense to allow the user to creat() their own files
> in this filesystem (with whatever descriptive name they need) and then
> pass that fd like:
> sys_perf_event_open(.group_fd=fd, .flags=PERF_FLAG_FD_DETACH);
> or something to associate the file with the event. Of course, that makes
> it very hard to create detached cgroup events :/

Yes, I like the idea of moving the burden of naming to the userspace,
but then we have a problem with inheritance, which would still produce
new events w/o user's input.

Maybe use a directory for the 'parent' event? Then the above would still


 \ /
  Last update: 2017-10-06 13:32    [W:0.056 / U:2.524 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site