linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Beau Belgrave <beaub@linux.microsoft.com>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: Masami Hiramatsu <mhiramat@kernel.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 10:17:47 -0700	[thread overview]
Message-ID: <20211013171747.GA1549@kbox> (raw)
In-Reply-To: <20211013131155.69fa0e11@gandalf.local.home>

On Wed, Oct 13, 2021 at 01:11:55PM -0400, Steven Rostedt wrote:
> On Wed, 13 Oct 2021 09:50:43 -0700
> Beau Belgrave <beaub@linux.microsoft.com> wrote:
> 
> > > Does it require RCU synchronization as the updates only happen from
> > > user space. But is this for the writing of the event? You want a
> > > separate fd for each event to write to, instead of saying you have
> > > another interface to write and just pass the given id?
> > >  
> > Yes, an example is a process creates the fd and registers some events.
> > Then the process forks and the child registers another event using the
> > same fd that was inherited.
> 
> Well, I was thinking simple locking could work too. But I guess RCU is like
> Batman. You know, "Always be yourself. Unless you can be Batman, then
> always be Batman!". So always use locking, unless you can use RCU,
> then always use RCU.
> 
LOL, I'm happy to use a rwlock_t instead. Not sure which is faster, to
me I care most about the write path not skewing clock times of the
events being emitted. It seems like the contention case will be low in
most cases, so these paths will be read-only most of the time.

It seems rwlock_t has the disadvantage of the writes blocking on the
realloc/free case during the resize. RCU can delay the free until
something has time to do so, so seems a good fit.

Thoughts?

Thanks,
-Beau

  reply	other threads:[~2021-10-13 17:17 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 [this message]
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
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=20211013171747.GA1549@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).