From: Joel Fernandes <joel@joelfernandes.org>
To: linux-kernel@vger.kernel.org
Cc: kernel-team@android.com,
"Joel Fernandes (Google)" <joel@joelfernandes.org>,
Boqun Feng <boqun.feng@gmail.com>,
Byungchul Park <byungchul.park@lge.com>,
Erick Reyes <erickreyes@google.com>,
Ingo Molnar <mingo@redhat.com>, Julia Cartwright <julia@ni.com>,
Masami Hiramatsu <mhiramat@kernel.org>,
Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
Namhyung Kim <namhyung@kernel.org>,
Paul McKenney <paulmck@linux.vnet.ibm.com>,
Peter Zijlstra <peterz@infradead.org>,
Steven Rostedt <rostedt@goodmis.org>,
Thomas Glexiner <tglx@linutronix.de>,
Todd Kjos <tkjos@google.com>,
Tom Zanussi <tom.zanussi@linux.intel.com>,
Will Deacon <will.deacon@arm.com>
Subject: [PATCH v10 0/3] tracing: Centralize preemptirq tracepoints and unify their usage
Date: Fri, 13 Jul 2018 14:55:44 -0700 [thread overview]
Message-ID: <20180713215547.255620-1-joel@joelfernandes.org> (raw)
From: "Joel Fernandes (Google)" <joel@joelfernandes.org>
This series contains the last 2 patches of the previous series, with
minor changes suggested by Peter and Steven, and an additional patch for
get_lock_stats cleanup suggested by Peter.
The preempt/irq tracepoints exist but not everything in the kernel is using it
whenever they need to be notified that a preempt disable/enable or an irq
disable/enable has occurred. This makes things not work simultaneously (for
example, only either lockdep or irqsoff trace-events can be used at a time).
This is particularly painful to deal with, since turning on lockdep breaks
tracers that install probes on IRQ events, such as the BCC atomic critical
section tracer [1]. This constraint also makes it not possible to use synthetic
events to trace irqsoff sections with lockdep simulataneously turned on.
This series solves that, and also results in a nice clean up of relevant parts
of the kernel. Several ifdefs are simpler, and the design is more unified and
better. Also as a result of this, we also speeded performance all rcuidle
tracepoints since their handling is simpler.
[1] https://github.com/iovisor/bcc/pull/1801/
v9->v10:
- Dropped first 3 and last 2 patches that were applied previously
- Folded SPDK license into the main patch introducing trace_preemptirq.c (Steve)
- Dropped lockdep_recursing & use simplify get_cpu_var instead (PeterZ)
- Simplify __DO_TRACE and use rcu_dereference_raw for both RCU and SRCU (PeterZ)
v8->v9:
- Small style changes to tracepoint code (Mathieu)
- Minor style fix to use PTR_ERR_OR_ZERO (0-day bot)
- Minor fix to test_atomic_sections to use unsigned long.
- Added Namhyung's, Mathieu's Reviewed-by to some patches.
v7->v8:
- Refactored irqsoff tracer probe defines (Namhyung)
v6->v7:
- Added a module to simulate an atomic section, a kselftest to load and
and trigger it which verifies the preempt-tracer and this series.
- Fixed a new warning after I rebased in early boot, this is because
early_boot_irqs_disabled was set too early, I moved it after the lockdep
initialization.
- added back the softirq fix since it appears it wasn't picked up.
- Ran Ingo's locking API selftest suite which are passing with this
series.
- Mathieu suggested ifdef'ing the tracepoint_synchronize_unregister
function incase tracepoints aren't enabled, did that.
Joel Fernandes (Google) (3):
lockdep: use this_cpu_ptr instead of get_cpu_var stats
tracepoint: Make rcuidle tracepoint callers use SRCU
tracing: Centralize preemptirq tracepoints and unify their usage
include/linux/ftrace.h | 11 +-
include/linux/irqflags.h | 11 +-
include/linux/lockdep.h | 8 +-
include/linux/preempt.h | 2 +-
include/linux/tracepoint.h | 45 ++++--
include/trace/events/preemptirq.h | 23 +--
init/main.c | 5 +-
kernel/locking/lockdep.c | 45 ++----
kernel/sched/core.c | 2 +-
kernel/trace/Kconfig | 22 ++-
kernel/trace/Makefile | 2 +-
kernel/trace/trace_irqsoff.c | 231 ++++++++----------------------
kernel/trace/trace_preemptirq.c | 72 ++++++++++
kernel/tracepoint.c | 16 ++-
14 files changed, 248 insertions(+), 247 deletions(-)
create mode 100644 kernel/trace/trace_preemptirq.c
--
2.18.0.203.gfac676dfb9-goog
next reply other threads:[~2018-07-13 21:55 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-07-13 21:55 Joel Fernandes [this message]
2018-07-13 21:55 ` [PATCH v10 1/3] lockdep: use this_cpu_ptr instead of get_cpu_var stats Joel Fernandes
2018-07-13 21:55 ` [PATCH v10 2/3] tracepoint: Make rcuidle tracepoint callers use SRCU Joel Fernandes
2018-07-14 14:31 ` Mathieu Desnoyers
2018-07-17 17:11 ` Joel Fernandes
2018-07-17 18:25 ` Peter Zijlstra
2018-07-17 20:15 ` Joel Fernandes
2018-07-18 0:16 ` Joel Fernandes
2018-07-18 8:21 ` Peter Zijlstra
2018-07-26 23:18 ` Steven Rostedt
2018-07-26 23:35 ` Joel Fernandes
2018-07-13 21:55 ` [PATCH v10 3/3] tracing: Centralize preemptirq tracepoints and unify their usage Joel Fernandes
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=20180713215547.255620-1-joel@joelfernandes.org \
--to=joel@joelfernandes.org \
--cc=boqun.feng@gmail.com \
--cc=byungchul.park@lge.com \
--cc=erickreyes@google.com \
--cc=julia@ni.com \
--cc=kernel-team@android.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mathieu.desnoyers@efficios.com \
--cc=mhiramat@kernel.org \
--cc=mingo@redhat.com \
--cc=namhyung@kernel.org \
--cc=paulmck@linux.vnet.ibm.com \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=tglx@linutronix.de \
--cc=tkjos@google.com \
--cc=tom.zanussi@linux.intel.com \
--cc=will.deacon@arm.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 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).