Re: [PATCH v2 00/14] perf, persistent: Kernel updates for perf toolintegration

[Robert Richter]

On 24.06.13 21:45:11, Ingo Molnar wrote:
> 
> * Peter Zijlstra <peterz@xxxxxxxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/