Re: [PATCH] user_events: Enable user processes to create and write to trace events

[Masami Hiramatsu <mhiramat@kernel.org>]

On Thu, 7 Oct 2021 17:05:40 -0700
Beau Belgrave <beaub@linux.microsoft.com> wrote:

> > > > > The other thing is we need ref counting to know if the event is busy.
> > > > > Having the ID in the packet avoids having a fd per-event, but it also
> > > > > makes ref counting process lifetime of each event quite hard.
> > > > 
> > > > Hmm, I don't think so. You can use an array of the pointer to
> > > > events on the private data of the struct file.
> > > > When you add (or start using) an event (this is identified by ioctl),
> > > > you can increment the event refcount and add it to the array.
> > > > When the file is closed (in exiting process), it will loop on the
> > > > array and decrement the refcount for each event.
> > > > Then, after all tracers disabled the event, ftrace can remove the
> > > > event in background (unless it is defined through 'dynamic_events' or
> > > > 'user_events').
> > > > 
> > > Yes, I didn't say it's impossible :) It's quite hard and takes a lot
> > > more management. I don't see a clear benefit to that approach, why is it
> > > better than an fd lifetime? Not trying to be difficult, just trying to
> > > be pragmatic about what approach is best.
> > 
> > I'm not sure this point, you mean 1 fd == 1 event model?
> > 
> Yeah, I like the idea of not having an fd per event.

Ah, OK. I misunderstood the idea.
per-FD model sounds like having events/user-events/*/marker file.

> I want to make
> sure the complexity is worth it. Is the overhead of an FD per event in
> user space too much?

It depends on the use case, how much events you wants to use with
the user-events. If there are hundreds of the evets, that will consume
kernel resources and /proc/*/fd/ will be filled with the event's fds.
But if there is a few events, I think no problem.

> What happens to the first 4 bytes (ID)? Does it not
> show up in the buffer?

You can add the 'ID' field commonly in the user-event by default
if you need it. Or, just skip the ID as it is a header of the packet.
(since the ID is process local number, that will not important for
the tracers who trace the events by name)

> This would be fine as long as the rel_loc idea
> gets into ftrace, etc.
> 
> This would require a global array as well as a local per-FD array. I'm
> wondering if the per-FD array becoming large mitigates the gain by
> simply having an FD per-event.

OK, I got it. I hope no one adds hundreds of events at once for
trace.

Thank you,


-- 
Masami Hiramatsu <mhiramat@kernel.org>