Re: [PATCH v3 12/12] [RFC] perf, persistent: ioctl functions tocontrol persistency

[Robert Richter]

Ok, starting with your question at the end first since it might
explain the following better.

If the event is no longer persistent and if there are multiple users,
the event remains open and running until the all mmap's are munmap'ed
and the last fd is closed. After that it is released. This is done
with refcounts and already implemented.

On 27.08.13 14:22:42, Borislav Petkov wrote:
> On Tue, Aug 27, 2013 at 01:54:22PM +0200, Robert Richter wrote:
> > I got another idea for this, what about UNCLAIM and CLAIM? It is
> > exactly, what it is. A process unclaims an event telling it doesn't
> > care anymore.  Another process comes and claims the event, meaning the
> > process wants the event no longer to be shared with others and being
> > released after closing.
> 
> This still doesn't pan out because with claiming the event, you state
> that the event is *owned* by this process but with persistent events
> we want to be able to state that they can have multiple users and thus
> multiple buffer consumers, concurrently.

We still have multiple users after 'claiming' the event. The only
thing is that the event will be destroyed after all users went away.
A process (that claimed the event) was responsible for this.

> > > > 3. ioctl DETACH from it so that it is "forked in the background" so to
> > > > speak, very similar to a background job in the shell.
> > 
> > With 'detach' we move the event into the 'background' so that it is
> > still available after opening.
> 
> Ok, maybe ATTACH/DETACH is not the perfect naming for this after all.
> Maybe when we want to state the fact that the event is going to continue
> existing after closing the buffer consumer, we want to do ioctl(event,
> DONT_DESTROY) and when we want to actually get rid of it, one of the
> process does ioctl(event, DESTROY).

I still prefer claim/unclaim. ;)

> Which reminds me, what do we do when one process destroys the event but
> there are other consumers accessing it concurrently? Refcounting?

See above.

-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/