On 24.06.13 21:45:11, Ingo Molnar wrote: > > * Peter Zijlstra <pet...@infradead.org> wrote: > > > Oh and what Boris and Ingo said; persistent events should 'persist' and > > not be tied to particular processes.
Fine with me too. But we need an answer how to create/release persistent events. It's easy to add them as in-kernel events in the kernel. But, how could persistent events be created from userspace without inventing too much new? As for standard events this could be done with the perf syscall too. The event is created by a process and buffers are also setup using the event's file descriptor. After the setup we detach the event from the process. The event is persistent now. We could release an event the same way by attaching it to a process an then closing it. Detaching an event from a process basically means the event is not released after the process is closing the event or is killed itself. Sharing an event between processes is very important for this. Sharing requires the event buffer to be accessed readonly and the event's ref count needs to keep track of all attached processes. As long as a process is using the event it is not released. But what options there are to detach the event from all processes and make it persistent? We could just put the creating process to sleep as long as the event should be persistent. This seems not to be an option for you. There could be other ways to just increase the refcount. We could use a ftrace-like approach and modify the refcount by: Detach: # echo opened_event > /sys/bus/event_source/devices/persistent/detached Release: # echo '!opened_event' > /sys/bus/event_source/devices/persistent/detached And Ingo's proposal using eventfs somehow: /sys/fs/events/user/PID/ And/or cgroups? Are there other suggestions? > > I'm not sure about the entire > > eventfs thing; but the proposed sysfs thing should definitely work for > > now. > > I'm fine with a sysfs approach as well, as long as it's correct and > obvious enough to use. Glad to hear this. :) Thanks, -Robert -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
