From: Beau Belgrave <beaub@linux.microsoft.com>
To: Masami Hiramatsu <mhiramat@kernel.org>
Cc: rostedt@goodmis.org, linux-trace-devel@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] user_events: Enable user processes to create and write to trace events
Date: Wed, 13 Oct 2021 09:56:14 -0700 [thread overview]
Message-ID: <20211013165614.GB1427@kbox> (raw)
In-Reply-To: <20211014002132.ee7668a4790ea75b0f7a9ceb@kernel.org>
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@linux.microsoft.com> 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
next prev parent reply other threads:[~2021-10-13 16:56 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-05 22:44 [PATCH] user_events: Enable user processes to create and write to trace events Beau Belgrave
2021-10-06 16:28 ` Masami Hiramatsu
2021-10-06 17:56 ` Beau Belgrave
2021-10-07 14:17 ` Masami Hiramatsu
2021-10-07 16:22 ` Beau Belgrave
2021-10-07 23:12 ` Masami Hiramatsu
2021-10-08 0:05 ` Beau Belgrave
2021-10-08 9:22 ` Masami Hiramatsu
2021-10-11 16:25 ` Beau Belgrave
2021-10-13 1:18 ` Steven Rostedt
2021-10-13 16:50 ` Beau Belgrave
2021-10-13 17:11 ` Steven Rostedt
2021-10-13 17:17 ` Beau Belgrave
2021-10-13 17:27 ` Steven Rostedt
2021-10-13 15:21 ` Masami Hiramatsu
2021-10-13 15:40 ` Steven Rostedt
2021-10-14 12:21 ` Masami Hiramatsu
2021-10-13 16:56 ` Beau Belgrave [this message]
2021-10-06 16:54 ` Steven Rostedt
2021-10-06 17:27 ` Beau Belgrave
2021-10-06 17:44 ` Steven Rostedt
2021-10-08 13:11 ` Peter.Enderborg
2021-10-08 16:09 ` Beau Belgrave
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20211013165614.GB1427@kbox \
--to=beaub@linux.microsoft.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-trace-devel@vger.kernel.org \
--cc=mhiramat@kernel.org \
--cc=rostedt@goodmis.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.