Re: [RFC PATCH 05/17] perf: Introduce detached events

[Alexander Shishkin <alexander.shishkin@linux.intel.com>]

Peter Zijlstra <peterz@infradead.org> 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.

Indeed.

>  - 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
work.

Regards,
--
Alex