[<prev] [next>] [day] [month] [year] [list]
Message-ID: <20251202172358.169eb8b2@gandalf.local.home>
Date: Tue, 2 Dec 2025 17:23:58 -0500
From: Steven Rostedt <rostedt@...dmis.org>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: LKML <linux-kernel@...r.kernel.org>, Masami Hiramatsu
<mhiramat@...nel.org>, Mark Rutland <mark.rutland@....com>, Mathieu
Desnoyers <mathieu.desnoyers@...icios.com>, Andrew Morton
<akpm@...ux-foundation.org>, Arnd Bergmann <arnd@...db.de>, Masahiro Yamada
<masahiroy@...nel.org>, Nathan Chancellor <nathan@...nel.org>, Nicolas
Schier <nicolas.schier@...ux.dev>, Nick Desaulniers
<nick.desaulniers+lkml@...il.com>, Catalin Marinas
<catalin.marinas@....com>, Bartosz Golaszewski
<bartosz.golaszewski@...aro.org>
Subject: [GIT PULL] tracing: Detect unused tracepoints at build time
Linus,
Detect unused tracepoints for v6.19:
If a tracepoint is defined but never used (TRACE_EVENT() created but no
trace_<tracepoint>() called), it can take up to or more than 5K of memory
each. This can add up as there are around a hundred unused tracepoints with
various configs. That is 500K of wasted memory.
Add a make build parameter of "UT=1" to have the build warn if an unused
tracepoint is detected in the build. This allows detection of unused
tracepoints to be upstream so that outreachy and the mentoring project can
have new developers look for fixing them, without having these warnings
suddenly show up when someone upgrades their kernel. When all known unused
tracepoints are removed, then the "UT=1" build parameter can be removed and
unused tracepoints will always warn. This will catch new unused tracepoints
after the current ones have been removed.
- Separate out elf functions from sorttable.c
Move out the ELF parsing functions from sorttable.c so that the tracing
tooling can use it.
- Add a tracepoint verifier tool to the build process
If "UT=1" is added to the kernel command line, any unused tracepoints will
trigger a warning at build time.
- Do not warn about unused tracepoints for tracepoints that are exported
There are sever cases where a tracepoint is created by the kernel and used
by modules. Since there's no easy way to detect if these are truly unused
since the users are in modules, if a tracepoint is exported, assume it
will eventually be used by a module. Note, there's not many exported
tracepoints so this should not be a problem to ignore them.
- Have building of modules also detect unused tracepoints
Do not only check the main vmlinux for unused tracepoints, also check
modules. If a module is defining a tracepoint it should be using it.
- Add the tracepoint-update program to the ignore file
The new tracepoint-update program needs to be ignored by git.
Please pull the latest tracepoints-v6.19 tree, which can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace.git
tracepoints-v6.19
Tag SHA1: 3dbffba951019f5f8ce851312f59ea30b7dff1b2
Head SHA1: b21f90e2e4503847ffeb00a9ef4d6d390291f902
Bartosz Golaszewski (1):
scripts: add tracepoint-update to the list of ignores files
Steven Rostedt (5):
sorttable: Move ELF parsing into scripts/elf-parse.[ch]
tracing: Add a tracepoint verification check at build time
tracepoint: Do not warn for unused event that is exported
tracing: Allow tracepoint-update.c to work with modules
tracing: Add warnings for unused tracepoints for modules
----
Makefile | 21 ++
include/asm-generic/vmlinux.lds.h | 1 +
include/linux/tracepoint.h | 13 ++
scripts/.gitignore | 1 +
scripts/Makefile | 6 +
scripts/Makefile.modfinal | 5 +
scripts/elf-parse.c | 198 ++++++++++++++++
scripts/elf-parse.h | 305 ++++++++++++++++++++++++
scripts/link-vmlinux.sh | 7 +
scripts/sorttable.c | 477 +++-----------------------------------
scripts/tracepoint-update.c | 261 +++++++++++++++++++++
11 files changed, 852 insertions(+), 443 deletions(-)
create mode 100644 scripts/elf-parse.c
create mode 100644 scripts/elf-parse.h
create mode 100644 scripts/tracepoint-update.c
---------------------------
Powered by blists - more mailing lists