On Thu, 7 Oct 2021 17:05:40 -0700 Beau Belgrave <beaub@xxxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxx>
|