Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Wed, 13 Oct 2021 09:56:14 -0700
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
Message-ID: <20211013165614.GB1427@kbox>
References: <20211005224428.2551-1-beaub@linux.microsoft.com>
 <20211007012827.99cd5795140cbb0c932e1b5a@kernel.org>
 <20211006175611.GA2995@kbox>
 <20211007231738.0626e348322dc09e7ebbf1d6@kernel.org>
 <20211007162204.GA30947@kbox>
 <20211008081249.8fbacc4f5d9fa7cf2e488d21@kernel.org>
 <20211008000540.GA31220@kbox>
 <20211008182258.6bf272e6691679d41e7971fc@kernel.org>
 <20211011162523.GA1542@kbox>
 <20211014002132.ee7668a4790ea75b0f7a9ceb@kernel.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20211014002132.ee7668a4790ea75b0f7a9ceb@kernel.org>
User-Agent: Mutt/1.9.4 (2018-02-28)
Precedence: bulk

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