Messages in this thread | | | From | Alexander Shishkin <> | Subject | Re: [RFC PATCH 05/17] perf: Introduce detached events | Date | Fri, 06 Oct 2017 14:23:03 +0300 |
| |
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
| |