All of lore.kernel.org
 help / color / mirror / Atom feed
From: Steven Rostedt <rostedt@goodmis.org>
To: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Cc: Alexei Starovoitov <alexei.starovoitov@gmail.com>,
	Peter Zijlstra <peterz@infradead.org>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	linux-arch <linux-arch@vger.kernel.org>,
	Ingo Molnar <mingo@kernel.org>,
	"Joel Fernandes, Google" <joel@joelfernandes.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	"Gustavo A. R. Silva" <gustavo@embeddedor.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	paulmck <paulmck@kernel.org>,
	Josh Triplett <josh@joshtriplett.org>,
	Lai Jiangshan <jiangshanlai@gmail.com>,
	Andy Lutomirski <luto@kernel.org>,
	Tony Luck <tony.luck@intel.com>,
	Frederic Weisbecker <frederic@kernel.org>,
	dan carpenter <dan.carpenter@oracle.com>,
	Masami Hiramatsu <mhiramat@kernel.org>
Subject: Re: [PATCH v4 16/27] tracing: Remove regular RCU context for _rcuidle tracepoints (again)
Date: Fri, 6 Mar 2020 15:45:56 -0500	[thread overview]
Message-ID: <20200306154556.6a829484@gandalf.local.home> (raw)
In-Reply-To: <609624365.20355.1583526166349.JavaMail.zimbra@efficios.com>

On Fri, 6 Mar 2020 15:22:46 -0500 (EST)
Mathieu Desnoyers <mathieu.desnoyers@efficios.com> wrote:

> I agree with the overall approach. Just a bit of nitpicking on the API:
> 
> I understand that the "prio" argument is a separate argument because it can take
> many values. However, "rcu" is just a boolean, so I wonder if we should not rather
> introduce a "int flags" with a bitmask enum, e.g.

I thought about this approach, but thought it was a bit overkill. As the
kernel doesn't have an internal API, I figured we can switch this over to
flags when we get another flag to add. Unless you can think of one in the
near future.

> 
> int tracepoint_probe_register_prio_flags(struct tracepoint *tp, void *probe,
>                                          void *data, int prio, int flags)
> 
> where flags would be populated through OR between labels of this enum:
> 
> enum tracepoint_flags {
>   TRACEPOINT_FLAG_RCU = (1U << 0),
> };
> 
> We can then be future-proof for additional flags without ending up calling e.g.
> 
> tracepoint_probe_register_featurea_featureb_featurec(tp, probe, data, 0, 1, 0, 1)

No, as soon as there is another boolean to add, the rcu version would be
switched to flags. I even thought about making the rcu and prio into one,
and change prio to be a SHRT_MAX max, and have the other 16 bits be for
flags.

-- Steve


> 
> which seems rather error-prone and less readable than a set of flags.


  reply	other threads:[~2020-03-06 20:46 UTC|newest]

Thread overview: 85+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-21 13:34 [PATCH v4 00/27] tracing vs world Peter Zijlstra
2020-02-21 13:34 ` [PATCH v4 01/27] lockdep: Teach lockdep about "USED" <- "IN-NMI" inversions Peter Zijlstra
2020-02-21 15:08   ` Steven Rostedt
2020-02-21 20:25     ` Peter Zijlstra
2020-02-21 20:28       ` Steven Rostedt
2020-02-21 22:01       ` Frederic Weisbecker
2020-02-22  3:08   ` Joel Fernandes
2020-02-24 10:10     ` Peter Zijlstra
2020-02-25  2:12       ` Joel Fernandes
2020-03-20 12:58   ` [tip: locking/core] " tip-bot2 for Peter Zijlstra
2020-02-21 13:34 ` [PATCH v4 02/27] hardirq/nmi: Allow nested nmi_enter() Peter Zijlstra
2020-02-21 22:21   ` Frederic Weisbecker
2020-02-24 12:13     ` Petr Mladek
2020-02-25  1:30       ` Frederic Weisbecker
2020-02-24 16:13     ` Peter Zijlstra
2020-02-25  3:09       ` Frederic Weisbecker
2020-02-25 15:41         ` Peter Zijlstra
2020-02-25 16:21           ` Frederic Weisbecker
2020-02-25 22:10           ` Frederic Weisbecker
2020-02-27  9:10             ` Peter Zijlstra
2020-02-27 13:34               ` Frederic Weisbecker
2020-02-21 13:34 ` [PATCH v4 03/27] x86/entry: Flip _TIF_SIGPENDING and _TIF_NOTIFY_RESUME handling Peter Zijlstra
2020-02-21 16:14   ` Peter Zijlstra
2020-02-21 13:34 ` [PATCH v4 04/27] x86/mce: Delete ist_begin_non_atomic() Peter Zijlstra
2020-02-21 19:07   ` Andy Lutomirski
2020-02-21 23:40   ` Frederic Weisbecker
2020-02-21 13:34 ` [PATCH v4 05/27] x86: Replace ist_enter() with nmi_enter() Peter Zijlstra
2020-02-21 19:05   ` Andy Lutomirski
2020-02-21 20:22     ` Peter Zijlstra
2020-02-24 10:43       ` Peter Zijlstra
2020-02-24 16:27         ` Steven Rostedt
2020-02-24 16:34           ` Peter Zijlstra
2020-02-24 16:47             ` Steven Rostedt
2020-02-24 21:31               ` Peter Zijlstra
2020-02-24 22:02                 ` Steven Rostedt
2020-02-26 10:25                   ` Peter Zijlstra
2020-02-26 13:16                     ` Peter Zijlstra
2020-02-26 10:27                   ` Peter Zijlstra
2020-02-26 15:20                     ` Steven Rostedt
2020-03-07  1:53                     ` Masami Hiramatsu
2020-02-21 13:34 ` [PATCH v4 06/27] x86/doublefault: Remove memmove() call Peter Zijlstra
2020-02-21 19:10   ` Andy Lutomirski
2020-02-21 13:34 ` [PATCH v4 07/27] rcu: Make RCU IRQ enter/exit functions rely on in_nmi() Peter Zijlstra
2020-02-26  0:23   ` Frederic Weisbecker
2020-02-21 13:34 ` [PATCH v4 08/27] rcu/kprobes: Comment why rcu_nmi_enter() is marked NOKPROBE Peter Zijlstra
2020-02-26  0:27   ` Frederic Weisbecker
2020-02-21 13:34 ` [PATCH v4 09/27] rcu: Rename rcu_irq_{enter,exit}_irqson() Peter Zijlstra
2020-02-21 20:21   ` Steven Rostedt
2020-02-24 10:24     ` Peter Zijlstra
2020-02-26  0:35   ` Frederic Weisbecker
2020-02-21 13:34 ` [PATCH v4 10/27] rcu: Mark rcu_dynticks_curr_cpu_in_eqs() inline Peter Zijlstra
2020-02-21 13:34 ` [PATCH v4 11/27] rcu,tracing: Create trace_rcu_{enter,exit}() Peter Zijlstra
2020-03-06 11:50   ` Peter Zijlstra
2020-03-06 12:40     ` Peter Zijlstra
2020-02-21 13:34 ` [PATCH v4 12/27] sched,rcu,tracing: Avoid tracing before in_nmi() is correct Peter Zijlstra
2020-02-21 13:34 ` [PATCH v4 13/27] x86,tracing: Add comments to do_nmi() Peter Zijlstra
2020-02-21 13:34 ` [PATCH v4 14/27] perf,tracing: Prepare the perf-trace interface for RCU changes Peter Zijlstra
2020-02-21 13:34 ` [PATCH v4 15/27] tracing: Employ trace_rcu_{enter,exit}() Peter Zijlstra
2020-02-21 13:34 ` [PATCH v4 16/27] tracing: Remove regular RCU context for _rcuidle tracepoints (again) Peter Zijlstra
2020-03-06 10:43   ` Peter Zijlstra
2020-03-06 11:31     ` Peter Zijlstra
2020-03-06 15:51       ` Alexei Starovoitov
2020-03-06 16:04         ` Mathieu Desnoyers
2020-03-06 17:55           ` Steven Rostedt
2020-03-06 18:45             ` Joel Fernandes
2020-03-06 18:59               ` Steven Rostedt
2020-03-06 19:14                 ` Joel Fernandes
2020-03-06 20:22             ` Mathieu Desnoyers
2020-03-06 20:45               ` Steven Rostedt [this message]
2020-03-06 20:55                 ` Mathieu Desnoyers
2020-03-06 21:06                   ` Steven Rostedt
2020-03-06 23:10                   ` Alexei Starovoitov
2020-03-06 17:21         ` Joel Fernandes
2020-02-21 13:34 ` [PATCH v4 17/27] perf,tracing: Allow function tracing when !RCU Peter Zijlstra
2020-02-21 13:34 ` [PATCH v4 18/27] x86/int3: Ensure that poke_int3_handler() is not traced Peter Zijlstra
2020-02-21 13:34 ` [PATCH v4 19/27] locking/atomics, kcsan: Add KCSAN instrumentation Peter Zijlstra
2020-02-21 13:34 ` [PATCH v4 20/27] asm-generic/atomic: Use __always_inline for pure wrappers Peter Zijlstra
2020-02-21 13:34 ` [PATCH v4 21/27] asm-generic/atomic: Use __always_inline for fallback wrappers Peter Zijlstra
2020-02-21 13:34 ` [PATCH v4 22/27] compiler: Simple READ/WRITE_ONCE() implementations Peter Zijlstra
2020-02-21 13:34 ` [PATCH v4 23/27] locking/atomics: Flip fallbacks and instrumentation Peter Zijlstra
2020-02-21 13:34 ` [PATCH v4 24/27] x86/int3: Avoid atomic instrumentation Peter Zijlstra
2020-02-21 13:34 ` [PATCH v4 25/27] lib/bsearch: Provide __always_inline variant Peter Zijlstra
2020-02-21 13:34 ` [PATCH v4 26/27] x86/int3: Inline bsearch() Peter Zijlstra
2020-02-21 13:34 ` [PATCH v4 27/27] x86/int3: Ensure that poke_int3_handler() is not sanitized Peter Zijlstra
2020-02-23 19:36   ` kbuild test robot

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=20200306154556.6a829484@gandalf.local.home \
    --to=rostedt@goodmis.org \
    --cc=alexei.starovoitov@gmail.com \
    --cc=dan.carpenter@oracle.com \
    --cc=frederic@kernel.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=gustavo@embeddedor.com \
    --cc=jiangshanlai@gmail.com \
    --cc=joel@joelfernandes.org \
    --cc=josh@joshtriplett.org \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=mathieu.desnoyers@efficios.com \
    --cc=mhiramat@kernel.org \
    --cc=mingo@kernel.org \
    --cc=paulmck@kernel.org \
    --cc=peterz@infradead.org \
    --cc=tglx@linutronix.de \
    --cc=tony.luck@intel.com \
    /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.