On Thu, Oct 14, 2021 at 12:21:32AM +0900, Masami Hiramatsu wrote: > On Mon, 11 Oct 2021 09:25:23 -0700 > Beau Belgrave <beaub@xxxxxxxxxxxxxxxxxxx> wrote: > > > On Fri, Oct 08, 2021 at 06:22:58PM +0900, Masami Hiramatsu wrote: > > > > > 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. > > > > > 2. > > We have a anon_inode FD that gets installed into the user process and > > returned via the ioctl from user_events tracefs file. The file struct > > backing the FD is shared by all user mode processes for that event. Like > > having an inject/marker file per-event in the user_events subsystem. > > Is it safe to share the same file structure among all processes? > (sharing FD via ipc may do same thing?) > I believe so, perf_event_open syscall uses this approach. I think sharing among processes would only be a problem if the file_operations methods assumed some synchronization. I don't see how this would be different than a fork inheriting a pre-existing FD. > > > > 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. > > > > > In our own use case this will be low due to the way we plan to use the > > events. However, I am not sure others will follow that :) > > I just concerned if qemu consider to use this interface for their event > log :) > Yep, agree. It sounds like taking an index'd approach as you first suggested is worth the complexity. I want to make sure you and Steven agree before attempting. Thanks, -Beau
|