* Re: [PATCH v4 7/7] kernel.h: drop trace_printk.h
From: Jani Nikula @ 2026-01-05 9:29 UTC (permalink / raw)
To: Yury Norov, Andy Shevchenko
Cc: Joel Fernandes, Steven Rostedt, Andrew Morton, Masami Hiramatsu,
Mathieu Desnoyers, Christophe Leroy, Randy Dunlap, Ingo Molnar,
Joonas Lahtinen, David Laight, Petr Pavlu, Andi Shyti,
Rodrigo Vivi, Tvrtko Ursulin, Daniel Gomez, Greg Kroah-Hartman,
Rafael J. Wysocki, Danilo Krummrich, linux-kernel, intel-gfx,
dri-devel, linux-modules, linux-trace-kernel
In-Reply-To: <aVkmQ4EGIQgAddZQ@yury>
On Sat, 03 Jan 2026, Yury Norov <yury.norov@gmail.com> wrote:
> On Sat, Jan 03, 2026 at 02:57:58PM +0200, Andy Shevchenko wrote:
>> On Fri, Jan 02, 2026 at 07:50:59PM -0500, Joel Fernandes wrote:
>> > On Mon, Dec 29, 2025 at 11:17:48AM -0500, Steven Rostedt wrote:
>>
>> ...
>>
>> > I use trace_printk() all the time for kernel, particularly RCU development.
>> > One of the key usecases I have is dumping traces on panic (with panic on warn
>> > and stop tracing on warn enabled). This is extremely useful since I can add
>> > custom tracing and dump traces when rare conditions occur. I fixed several
>> > bugs with this technique.
>> >
>> > I also recommend keeping it convenient to use.
>>
>> Okay, you know C, please share your opinion what header is the best to hold the
>> trace_printk.h to be included.
>
> What if we include it on Makefile level, similarly to how W=1 works?
>
> make D=1 // trace_printk() is available
> make D=0 // trace_printk() is not available
> make // trace_printk() is not available
>
> Where D stands for debugging.
>
> D=1 may be a default setting if you prefer, but the most important is
> that every compilation unit will have an access to debugging without
> polluting core headers.
You do realize this means recompiling everything when adding D=1 for
debugging?
BR,
Jani.
--
Jani Nikula, Intel
^ permalink raw reply
* Re: [PATCH 2/5] tracing/osnoise: Dump stack on timerlat uret threshold event
From: Tomas Glozar @ 2026-01-05 9:30 UTC (permalink / raw)
To: Crystal Wood
Cc: Steven Rostedt, linux-trace-kernel, John Kacur, Costa Shulyupin,
Wander Lairson Costa, Attila Fazekas
In-Reply-To: <20251112152529.956778-3-crwood@redhat.com>
st 12. 11. 2025 v 16:25 odesílatel Crystal Wood <crwood@redhat.com> napsal:
>
> Dump the saved IRQ stack trace regardless of whether the event was
> THREAD_CONTEXT or THREAD_URET.
>
> In the uret case, the latency presumably had not yet crossed the
> threshold at IRQ time (or else it would have dumped the stack at thread
> wakeup time, unless we're racing with a change to the threshold), but it
> may have at least contributed -- and this is possible with THREAD_CONTEXT
> as well.
>
> In any case, it helps with writing reliable rtla tests if we always get
> a stack trace on a threshold event.
>
Thank you. The omitting of dumping stack in the uret part of
timerlat_fd_read() looks like a bug to me, I don't see any reason for
it being done for thread latency but not for uret latency, especially
considering the existence of the -a option. Without the patch, -a
behaves differently with kernel and user threads - with kernel
threads, it will always dump the stack on stop tracing if possible,
but with user threads, it will only dump it if the thread latency is
over the threshold.
The help message says:
-s/--stack us: save the stack trace at the IRQ if a thread latency
is higher than the argument in us
but just like in the case of [1], the current behavior (without the
patch) is not natural and no user is going to expect it. (Yes, the
documentation needs updating...)
Compare rtla -a behavior without the patch (auto-analysis without stack):
$ rtla timerlat hist -a 20 --warm-up 2 -c 1
...
max: 3 18 30
timerlat hit stop tracing
## CPU 1 hit stop tracing, analyzing it ##
IRQ handler delay: 0.00 us (0.00 %)
IRQ latency: 3.73 us
Timerlat IRQ duration: 10.66 us (35.39 %)
Blocking thread: 2.94 us (9.77 %)
swapper/1:0 2.94 us
------------------------------------------------------------------------
Thread latency: 30.11 us (100%)
with the behavior with the patch (auto-analysis with stack):
$ rtla timerlat hist -a 20 --warm-up 2 -c 1
...
max: 4 19 23
timerlat hit stop tracing
## CPU 1 hit stop tracing, analyzing it ##
IRQ handler delay: 0.00 us (0.00 %)
IRQ latency: 4.10 us
Timerlat IRQ duration: 9.65
us (41.79 %)
Blocking thread: 4.58
us (19.81 %)
swapper/1:0 4.58 us
Blocking thread stack trace
-> timerlat_irq
...
-> common_startup_64
------------------------------------------------------------------------
Thread latency: 23.11 us (100%)
Tested-by: Tomas Glozar <tglozar@redhat.com>
Reviewed-by: Tomas Glozar <tglozar@redhat.com>
[1] https://lore.kernel.org/linux-trace-kernel/20251006143100.137255-1-tglozar@redhat.com/
Tomas
^ permalink raw reply
* [v2 PATCH 0/2] tracing: Expose global views of active filters and triggers
From: Aaron Tomlin @ 2026-01-05 14:29 UTC (permalink / raw)
To: rostedt, mhiramat, mark.rutland, mathieu.desnoyers, corbet
Cc: neelx, sean, linux-kernel, linux-trace-kernel, linux-doc
Hi Steve,
Currently, auditing active Ftrace event filters or triggers requires userspace
to recursively traverse the "events/" directory and read the "filter" or
"trigger" file for every individual event. For monitoring tools, security
auditors, or developers debugging complex tracing setups, this O(n) traversal
is inefficient and cumbersome.
This series introduces two new files at the trace root directory to provide
a consolidated, system-wide view of active event configurations:
1. show_event_filters: Displays all events with an active filter
2. show_event_triggers: Displays all events with active triggers
Both files utilise the system:event [tab] config format, allowing for easy
parsing by standard tools (e.g., awk) or custom monitoring agents.
The patches leverage the existing trace_event_file iterators to ensure atomic
and efficient traversal of the event list. Scope-based RCU protection
(guard(rcu)) is used for filter string access, whilst the existing event_mutex
protection within the iterator ensures safe traversal of the event trigger
lists. For triggers, we utilise the internal cmd_ops->print() callbacks to
guarantee that the consolidated output remains consistent with the legacy
per-event interface.
Changes since v1 [1]:
- Clarified that all events with filters are listed, regardless of
enablement state (Steven Rostedt)
- Optimise filter display logic by utilising the guard(rcu) macro for cleaner
scope-based RCU protection and early return (Steven Rostedt)
- Add show_event_triggers to expose event triggers alongside filters
(Steven Rostedt)
[1]: https://lore.kernel.org/lkml/20260101233414.2476973-1-atomlin@atomlin.com/
Aaron Tomlin (2):
tracing: Add show_event_filters to expose active event filters
tracing: Add show_event_triggers to expose active event triggers
Documentation/trace/ftrace.rst | 16 +++++
kernel/trace/trace_events.c | 122 +++++++++++++++++++++++++++++++++
2 files changed, 138 insertions(+)
--
2.51.0
^ permalink raw reply
* [v2 PATCH 1/2] tracing: Add show_event_filters to expose active event filters
From: Aaron Tomlin @ 2026-01-05 14:29 UTC (permalink / raw)
To: rostedt, mhiramat, mark.rutland, mathieu.desnoyers, corbet
Cc: neelx, sean, linux-kernel, linux-trace-kernel, linux-doc
In-Reply-To: <20260105142939.2655342-1-atomlin@atomlin.com>
Currently, to audit active Ftrace event filters, userspace must
recursively traverse the events/ directory and read each individual
filter file. This is inefficient for monitoring tools and debugging.
Introduce "show_event_filters" at the trace root directory. This file
displays all events that currently have a filter applied, alongside the
actual filter string, in a consolidated system:event [tab] filter
format.
The implementation reuses the existing trace_event_file iterators to
ensure atomic traversal of the event list and utilises guard(rcu)() for
automatic, scope-based protection when accessing volatile filter
strings.
Signed-off-by: Aaron Tomlin <atomlin@atomlin.com>
---
Documentation/trace/ftrace.rst | 8 +++++
kernel/trace/trace_events.c | 58 ++++++++++++++++++++++++++++++++++
2 files changed, 66 insertions(+)
diff --git a/Documentation/trace/ftrace.rst b/Documentation/trace/ftrace.rst
index 639f4d95732f..4ce01e726b09 100644
--- a/Documentation/trace/ftrace.rst
+++ b/Documentation/trace/ftrace.rst
@@ -684,6 +684,14 @@ of ftrace. Here is a list of some of the key files:
See events.rst for more information.
+ show_event_filters:
+
+ A list of events that have filters. This shows the
+ system/event pair along with the filter that is attached to
+ the event.
+
+ See events.rst for more information.
+
available_events:
A list of events that can be enabled in tracing.
diff --git a/kernel/trace/trace_events.c b/kernel/trace/trace_events.c
index b16a5a158040..5ede4214c4df 100644
--- a/kernel/trace/trace_events.c
+++ b/kernel/trace/trace_events.c
@@ -1661,6 +1661,32 @@ static void t_stop(struct seq_file *m, void *p)
mutex_unlock(&event_mutex);
}
+/**
+ * t_show_filters - seq_file callback to display active event filters
+ * @m: The seq_file interface for formatted output
+ * @v: The current trace_event_file being iterated
+ *
+ * Identifies and prints active filters for the current event file in the
+ * iteration. If a filter is applied to the current event and, if so,
+ * prints the system name, event name, and the filter string.
+ */
+static int t_show_filters(struct seq_file *m, void *v)
+{
+ struct trace_event_file *file = v;
+ struct trace_event_call *call = file->event_call;
+ struct event_filter *filter;
+
+ guard(rcu)();
+ filter = rcu_dereference(file->filter);
+ if (!filter || !filter->filter_string)
+ return 0;
+
+ seq_printf(m, "%s:%s\t%s\n", call->class->system,
+ trace_event_name(call), filter->filter_string);
+
+ return 0;
+}
+
#ifdef CONFIG_MODULES
static int s_show(struct seq_file *m, void *v)
{
@@ -2488,6 +2514,7 @@ ftrace_event_npid_write(struct file *filp, const char __user *ubuf,
static int ftrace_event_avail_open(struct inode *inode, struct file *file);
static int ftrace_event_set_open(struct inode *inode, struct file *file);
+static int ftrace_event_show_filters_open(struct inode *inode, struct file *file);
static int ftrace_event_set_pid_open(struct inode *inode, struct file *file);
static int ftrace_event_set_npid_open(struct inode *inode, struct file *file);
static int ftrace_event_release(struct inode *inode, struct file *file);
@@ -2506,6 +2533,13 @@ static const struct seq_operations show_set_event_seq_ops = {
.stop = s_stop,
};
+static const struct seq_operations show_show_event_filters_seq_ops = {
+ .start = t_start,
+ .next = t_next,
+ .show = t_show_filters,
+ .stop = t_stop,
+};
+
static const struct seq_operations show_set_pid_seq_ops = {
.start = p_start,
.next = p_next,
@@ -2535,6 +2569,13 @@ static const struct file_operations ftrace_set_event_fops = {
.release = ftrace_event_release,
};
+static const struct file_operations ftrace_show_event_filters_fops = {
+ .open = ftrace_event_show_filters_open,
+ .read = seq_read,
+ .llseek = seq_lseek,
+ .release = seq_release,
+};
+
static const struct file_operations ftrace_set_event_pid_fops = {
.open = ftrace_event_set_pid_open,
.read = seq_read,
@@ -2679,6 +2720,20 @@ ftrace_event_set_open(struct inode *inode, struct file *file)
return ret;
}
+/**
+ * ftrace_event_show_filters_open - open interface for set_event_filters
+ * @inode: The inode of the file
+ * @file: The file being opened
+ *
+ * Connects the set_event_filters file to the sequence operations
+ * required to iterate over and display active event filters.
+ */
+static int
+ftrace_event_show_filters_open(struct inode *inode, struct file *file)
+{
+ return ftrace_event_open(inode, file, &show_show_event_filters_seq_ops);
+}
+
static int
ftrace_event_set_pid_open(struct inode *inode, struct file *file)
{
@@ -4399,6 +4454,9 @@ create_event_toplevel_files(struct dentry *parent, struct trace_array *tr)
if (!entry)
return -ENOMEM;
+ trace_create_file("show_event_filters", TRACE_MODE_READ, parent, tr,
+ &ftrace_show_event_filters_fops);
+
nr_entries = ARRAY_SIZE(events_entries);
e_events = eventfs_create_events_dir("events", parent, events_entries,
--
2.51.0
^ permalink raw reply related
* [v2 PATCH 2/2] tracing: Add show_event_triggers to expose active event triggers
From: Aaron Tomlin @ 2026-01-05 14:29 UTC (permalink / raw)
To: rostedt, mhiramat, mark.rutland, mathieu.desnoyers, corbet
Cc: neelx, sean, linux-kernel, linux-trace-kernel, linux-doc
In-Reply-To: <20260105142939.2655342-1-atomlin@atomlin.com>
To audit active event triggers, userspace currently must traverse the
events/ directory and read each individual trigger file. This is
cumbersome for system-wide auditing or debugging.
Introduce "show_event_triggers" at the trace root directory. This file
displays all events that currently have one or more triggers applied,
alongside the trigger configuration, in a consolidated
system:event [tab] trigger format.
The implementation leverages the existing trace_event_file iterators
and uses the trigger's own print() operation to ensure output
consistency with the per-event trigger files.
Signed-off-by: Aaron Tomlin <atomlin@atomlin.com>
---
Documentation/trace/ftrace.rst | 8 +++++
kernel/trace/trace_events.c | 64 ++++++++++++++++++++++++++++++++++
2 files changed, 72 insertions(+)
diff --git a/Documentation/trace/ftrace.rst b/Documentation/trace/ftrace.rst
index 4ce01e726b09..b9efb148a5c2 100644
--- a/Documentation/trace/ftrace.rst
+++ b/Documentation/trace/ftrace.rst
@@ -692,6 +692,14 @@ of ftrace. Here is a list of some of the key files:
See events.rst for more information.
+ show_event_triggers:
+
+ A list of events that have triggers. This shows the
+ system/event pair along with the trigger that is attached to
+ the event.
+
+ See events.rst for more information.
+
available_events:
A list of events that can be enabled in tracing.
diff --git a/kernel/trace/trace_events.c b/kernel/trace/trace_events.c
index 5ede4214c4df..e2a67561253d 100644
--- a/kernel/trace/trace_events.c
+++ b/kernel/trace/trace_events.c
@@ -1687,6 +1687,38 @@ static int t_show_filters(struct seq_file *m, void *v)
return 0;
}
+/**
+ * t_show_triggers - seq_file callback to display active event triggers
+ * @m: The seq_file interface for formatted output
+ * @v: The current trace_event_file being iterated
+ *
+ * Iterates through the trigger list of the current event file and prints
+ * each active trigger's configuration using its associated print
+ * operation.
+ */
+static int t_show_triggers(struct seq_file *m, void *v)
+{
+ struct trace_event_file *file = v;
+ struct trace_event_call *call = file->event_call;
+ struct event_trigger_data *data;
+
+ /*
+ * The event_mutex is held by t_start(), protecting the
+ * file->triggers list traversal.
+ */
+ if (list_empty(&file->triggers))
+ return 0;
+
+ list_for_each_entry_rcu(data, &file->triggers, list) {
+ seq_printf(m, "%s:%s\t", call->class->system,
+ trace_event_name(call));
+
+ data->cmd_ops->print(m, data);
+ }
+
+ return 0;
+}
+
#ifdef CONFIG_MODULES
static int s_show(struct seq_file *m, void *v)
{
@@ -2515,6 +2547,7 @@ ftrace_event_npid_write(struct file *filp, const char __user *ubuf,
static int ftrace_event_avail_open(struct inode *inode, struct file *file);
static int ftrace_event_set_open(struct inode *inode, struct file *file);
static int ftrace_event_show_filters_open(struct inode *inode, struct file *file);
+static int ftrace_event_show_triggers_open(struct inode *inode, struct file *file);
static int ftrace_event_set_pid_open(struct inode *inode, struct file *file);
static int ftrace_event_set_npid_open(struct inode *inode, struct file *file);
static int ftrace_event_release(struct inode *inode, struct file *file);
@@ -2540,6 +2573,13 @@ static const struct seq_operations show_show_event_filters_seq_ops = {
.stop = t_stop,
};
+static const struct seq_operations show_show_event_triggers_seq_ops = {
+ .start = t_start,
+ .next = t_next,
+ .show = t_show_triggers,
+ .stop = t_stop,
+};
+
static const struct seq_operations show_set_pid_seq_ops = {
.start = p_start,
.next = p_next,
@@ -2576,6 +2616,13 @@ static const struct file_operations ftrace_show_event_filters_fops = {
.release = seq_release,
};
+static const struct file_operations ftrace_show_event_triggers_fops = {
+ .open = ftrace_event_show_triggers_open,
+ .read = seq_read,
+ .llseek = seq_lseek,
+ .release = seq_release,
+};
+
static const struct file_operations ftrace_set_event_pid_fops = {
.open = ftrace_event_set_pid_open,
.read = seq_read,
@@ -2734,6 +2781,20 @@ ftrace_event_show_filters_open(struct inode *inode, struct file *file)
return ftrace_event_open(inode, file, &show_show_event_filters_seq_ops);
}
+/**
+ * ftrace_event_show_triggers_open - open interface for show_event_triggers
+ * @inode: The inode of the file
+ * @file: The file being opened
+ *
+ * Connects the show_event_triggers file to the sequence operations
+ * required to iterate over and display active event triggers.
+ */
+static int
+ftrace_event_show_triggers_open(struct inode *inode, struct file *file)
+{
+ return ftrace_event_open(inode, file, &show_show_event_triggers_seq_ops);
+}
+
static int
ftrace_event_set_pid_open(struct inode *inode, struct file *file)
{
@@ -4457,6 +4518,9 @@ create_event_toplevel_files(struct dentry *parent, struct trace_array *tr)
trace_create_file("show_event_filters", TRACE_MODE_READ, parent, tr,
&ftrace_show_event_filters_fops);
+ trace_create_file("show_event_triggers", TRACE_MODE_READ, parent, tr,
+ &ftrace_show_event_triggers_fops);
+
nr_entries = ARRAY_SIZE(events_entries);
e_events = eventfs_create_events_dir("events", parent, events_entries,
--
2.51.0
^ permalink raw reply related
* Re: [PATCH 3/5] tracing: Have tracer option be instance specific
From: Dan Carpenter @ 2026-01-05 15:23 UTC (permalink / raw)
To: oe-kbuild, Steven Rostedt, linux-kernel, linux-trace-kernel
Cc: lkp, oe-kbuild-all, Masami Hiramatsu, Mark Rutland,
Mathieu Desnoyers, Andrew Morton, Linux Memory Management List
In-Reply-To: <20251105161935.545400234@kernel.org>
Hi Steven,
kernel test robot noticed the following build warnings:
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Steven-Rostedt/tracing-Remove-dummy-options-and-flags/20251106-010511
base: https://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace for-next
patch link: https://lore.kernel.org/r/20251105161935.545400234%40kernel.org
patch subject: [PATCH 3/5] tracing: Have tracer option be instance specific
config: i386-randconfig-r072-20251107 (https://download.01.org/0day-ci/archive/20251107/202511071533.domGENBS-lkp@intel.com/config)
compiler: clang version 20.1.8 (https://github.com/llvm/llvm-project 87f0227cb60147a26a1eeb4fb06e3b505e9c7261)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Reported-by: Dan Carpenter <dan.carpenter@linaro.org>
| Closes: https://lore.kernel.org/r/202511071533.domGENBS-lkp@intel.com/
smatch warnings:
kernel/trace/trace.c:6313 tracing_set_tracer() warn: iterator used outside loop: 't'
vim +/t +6313 kernel/trace/trace.c
9c5b9d3d65e4858 Masami Hiramatsu 2020-01-11 6285 int tracing_set_tracer(struct trace_array *tr, const char *buf)
09d23a1d8a82e81 Steven Rostedt (Red Hat 2015-02-03 6286) {
4699bbb369ba1d3 Steven Rostedt 2025-11-05 6287 struct tracer *trace;
4699bbb369ba1d3 Steven Rostedt 2025-11-05 6288 struct tracers *t;
12883efb670c28d Steven Rostedt (Red Hat 2013-03-05 6289) #ifdef CONFIG_TRACER_MAX_TRACE
34600f0e9c33c9c Steven Rostedt 2013-01-22 6290 bool had_max_tr;
12883efb670c28d Steven Rostedt (Red Hat 2013-03-05 6291) #endif
d33b10c0c73adca Steven Rostedt 2024-12-24 6292 int ret;
bc0c38d139ec7fc Steven Rostedt 2008-05-12 6293
d33b10c0c73adca Steven Rostedt 2024-12-24 6294 guard(mutex)(&trace_types_lock);
1027fcb206a0fb8 Steven Rostedt 2009-03-12 6295
7a1d1e4b9639ff0 Steven Rostedt (Google 2024-06-12 6296) update_last_data(tr);
7a1d1e4b9639ff0 Steven Rostedt (Google 2024-06-12 6297)
a1f157c7a3bb342 Zheng Yejian 2023-09-06 6298 if (!tr->ring_buffer_expanded) {
2b6080f28c7cc3e Steven Rostedt 2012-05-11 6299 ret = __tracing_resize_ring_buffer(tr, trace_buf_size,
438ced1720b5840 Vaibhav Nagarnaik 2012-02-02 6300 RING_BUFFER_ALL_CPUS);
73c5162aa362a54 Steven Rostedt 2009-03-11 6301 if (ret < 0)
d33b10c0c73adca Steven Rostedt 2024-12-24 6302 return ret;
73c5162aa362a54 Steven Rostedt 2009-03-11 6303 ret = 0;
73c5162aa362a54 Steven Rostedt 2009-03-11 6304 }
73c5162aa362a54 Steven Rostedt 2009-03-11 6305
4699bbb369ba1d3 Steven Rostedt 2025-11-05 6306 list_for_each_entry(t, &tr->tracers, list) {
4699bbb369ba1d3 Steven Rostedt 2025-11-05 6307 if (strcmp(t->tracer->name, buf) == 0)
bc0c38d139ec7fc Steven Rostedt 2008-05-12 6308 break;
bc0c38d139ec7fc Steven Rostedt 2008-05-12 6309 }
d33b10c0c73adca Steven Rostedt 2024-12-24 6310 if (!t)
t can't be NULL here. It needs to be if (list_entry_is_head()) return;
d33b10c0c73adca Steven Rostedt 2024-12-24 6311 return -EINVAL;
d33b10c0c73adca Steven Rostedt 2024-12-24 6312
4699bbb369ba1d3 Steven Rostedt 2025-11-05 @6313 if (t->tracer == tr->current_trace)
d33b10c0c73adca Steven Rostedt 2024-12-24 6314 return 0;
bc0c38d139ec7fc Steven Rostedt 2008-05-12 6315
4699bbb369ba1d3 Steven Rostedt 2025-11-05 6316 trace = t->tracer;
4699bbb369ba1d3 Steven Rostedt 2025-11-05 6317
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* [PATCH v3 0/2] mm: vmscan: add PID and cgroup ID to vmscan tracepoints
From: Thomas Ballasi @ 2026-01-05 16:04 UTC (permalink / raw)
To: tballasi; +Cc: akpm, linux-mm, linux-trace-kernel, mhiramat, rostedt
In-Reply-To: <20251216140252.11864-1-tballasi@linux.microsoft.com>
Changes in v3:
- Swapped multiple field entries to prevent a hole in the ring buffer
- Replaced in_task() with __event_in_irq
- Replaced mem_cgroup_id(memcg) with cgroup_id(memcg->css.cgroup)
- Rebased the tree to latest 6.18
Link to v2:
https://lore.kernel.org/linux-trace-kernel/20251216140252.11864-1-tballasi@linux.microsoft.com/
Signed-off-by: Thomas Ballasi <tballasi@linux.microsoft.com>
Thomas Ballasi (2):
mm: vmscan: add cgroup IDs to vmscan tracepoints
mm: vmscan: add PIDs to vmscan tracepoints
include/trace/events/vmscan.h | 100 ++++++++++++++++++++++------------
mm/shrinker.c | 2 +-
mm/vmscan.c | 17 +++---
3 files changed, 74 insertions(+), 45 deletions(-)
--
2.33.8
^ permalink raw reply
* [PATCH v3 2/2] mm: vmscan: add PIDs to vmscan tracepoints
From: Thomas Ballasi @ 2026-01-05 16:04 UTC (permalink / raw)
To: tballasi; +Cc: akpm, linux-mm, linux-trace-kernel, mhiramat, rostedt
In-Reply-To: <20260105160423.23708-1-tballasi@linux.microsoft.com>
The changes aims at adding additionnal tracepoints variables to help
debuggers attribute them to specific processes.
The PID field uses in_task() to reliably detect when we're in process
context and can safely access current->pid. When not in process
context (such as in interrupt or in an asynchronous RCU context), the
field is set to -1 as a sentinel value.
Signed-off-by: Thomas Ballasi <tballasi@linux.microsoft.com>
---
include/trace/events/vmscan.h | 33 ++++++++++++++++++++++++---------
1 file changed, 24 insertions(+), 9 deletions(-)
diff --git a/include/trace/events/vmscan.h b/include/trace/events/vmscan.h
index 93a9a9ba9405d..d438abfa03ebb 100644
--- a/include/trace/events/vmscan.h
+++ b/include/trace/events/vmscan.h
@@ -121,19 +121,23 @@ DECLARE_EVENT_CLASS(mm_vmscan_direct_reclaim_begin_template,
TP_STRUCT__entry(
__field( unsigned long, gfp_flags )
__field( int, order )
+ __field( int, pid )
__field( unsigned short, memcg_id )
),
TP_fast_assign(
__entry->gfp_flags = (__force unsigned long)gfp_flags;
__entry->order = order;
+ __entry->pid = current->pid;
__entry->memcg_id = memcg_id;
),
- TP_printk("order=%d gfp_flags=%s memcg_id=%u",
+ TP_printk("order=%d gfp_flags=%s pid=%d memcg_id=%u %s",
__entry->order,
show_gfp_flags(__entry->gfp_flags),
- __entry->memcg_id)
+ __entry->pid,
+ __entry->memcg_id,
++ __event_in_irq() ? "(in-irq)" : "")
);
DEFINE_EVENT(mm_vmscan_direct_reclaim_begin_template, mm_vmscan_direct_reclaim_begin,
@@ -167,17 +171,21 @@ DECLARE_EVENT_CLASS(mm_vmscan_direct_reclaim_end_template,
TP_STRUCT__entry(
__field( unsigned long, nr_reclaimed )
+ __field( int, pid )
__field( unsigned short, memcg_id )
),
TP_fast_assign(
__entry->nr_reclaimed = nr_reclaimed;
+ __entry->pid = current->pid;
__entry->memcg_id = memcg_id;
),
- TP_printk("nr_reclaimed=%lu memcg_id=%u",
+ TP_printk("nr_reclaimed=%lu pid=%d memcg_id=%u %s",
__entry->nr_reclaimed,
- __entry->memcg_id)
+ __entry->pid,
+ __entry->memcg_id,
+ __event_in_irq() ? "(in-irq)" : "")
);
DEFINE_EVENT(mm_vmscan_direct_reclaim_end_template, mm_vmscan_direct_reclaim_end,
@@ -222,6 +230,7 @@ TRACE_EVENT(mm_shrink_slab_start,
__field(unsigned long, total_scan)
__field(int, priority)
__field(int, nid)
+ __field(int, pid)
__field(unsigned short, memcg_id)
),
@@ -235,20 +244,23 @@ TRACE_EVENT(mm_shrink_slab_start,
__entry->total_scan = total_scan;
__entry->priority = priority;
__entry->nid = sc->nid;
+ __entry->pid = current->pid;
__entry->memcg_id = sc->memcg ? cgroup_id(sc->memcg->css.cgroup) : 0;
),
- TP_printk("%pS %p: nid: %d memcg_id: %u objects to shrink %ld gfp_flags %s cache items %ld delta %lld total_scan %ld priority %d",
+ TP_printk("%pS %p: nid: %d pid: %d memcg_id: %u objects to shrink %ld gfp_flags %s cache items %ld delta %lld total_scan %ld priority %d %s",
__entry->shrink,
__entry->shr,
__entry->nid,
+ __entry->pid,
__entry->memcg_id,
__entry->nr_objects_to_shrink,
show_gfp_flags(__entry->gfp_flags),
__entry->cache_items,
__entry->delta,
__entry->total_scan,
- __entry->priority)
+ __entry->priority,
++ __event_in_irq() ? "(in-irq)" : "")
);
TRACE_EVENT(mm_shrink_slab_end,
@@ -266,29 +278,32 @@ TRACE_EVENT(mm_shrink_slab_end,
__field(long, total_scan)
__field(int, nid)
__field(int, retval)
+ __field(int, pid)
__field(unsigned short, memcg_id)
),
TP_fast_assign(
__entry->shr = shr;
- __entry->shrink = shr->scan_objects;
__entry->unused_scan = unused_scan_cnt;
__entry->new_scan = new_scan_cnt;
__entry->total_scan = total_scan;
__entry->nid = sc->nid;
__entry->retval = shrinker_retval;
+ __entry->pid = current->pid;
__entry->memcg_id = cgroup_id(sc->memcg->css.cgroup);
),
- TP_printk("%pS %p: nid: %d memcg_id: %u unused scan count %ld new scan count %ld total_scan %ld last shrinker return val %d",
+ TP_printk("%pS %p: nid: %d pid: %d memcg_id: %u unused scan count %ld new scan count %ld total_scan %ld last shrinker return val %d %s",
__entry->shrink,
__entry->shr,
__entry->nid,
+ __entry->pid,
__entry->memcg_id,
__entry->unused_scan,
__entry->new_scan,
__entry->total_scan,
- __entry->retval)
+ __entry->retval,
++ __event_in_irq() ? "(in-irq)" : "")
);
TRACE_EVENT(mm_vmscan_lru_isolate,
--
2.33.8
^ permalink raw reply related
* [PATCH v3 1/2] mm: vmscan: add cgroup IDs to vmscan tracepoints
From: Thomas Ballasi @ 2026-01-05 16:04 UTC (permalink / raw)
To: tballasi; +Cc: akpm, linux-mm, linux-trace-kernel, mhiramat, rostedt
In-Reply-To: <20260105160423.23708-1-tballasi@linux.microsoft.com>
Memory reclaim events are currently difficult to attribute to
specific cgroups, making debugging memory pressure issues
challenging. This patch adds memory cgroup ID (memcg_id) to key
vmscan tracepoints to enable better correlation and analysis.
For operations not associated with a specific cgroup, the field
is defaulted to 0.
Signed-off-by: Thomas Ballasi <tballasi@linux.microsoft.com>
---
include/trace/events/vmscan.h | 79 ++++++++++++++++++++---------------
mm/shrinker.c | 2 +-
mm/vmscan.c | 17 ++++----
3 files changed, 56 insertions(+), 42 deletions(-)
diff --git a/include/trace/events/vmscan.h b/include/trace/events/vmscan.h
index 490958fa10dee..93a9a9ba9405d 100644
--- a/include/trace/events/vmscan.h
+++ b/include/trace/events/vmscan.h
@@ -114,85 +114,92 @@ TRACE_EVENT(mm_vmscan_wakeup_kswapd,
DECLARE_EVENT_CLASS(mm_vmscan_direct_reclaim_begin_template,
- TP_PROTO(int order, gfp_t gfp_flags),
+ TP_PROTO(gfp_t gfp_flags, int order, unsigned short memcg_id),
- TP_ARGS(order, gfp_flags),
+ TP_ARGS(gfp_flags, order, memcg_id),
TP_STRUCT__entry(
- __field( int, order )
__field( unsigned long, gfp_flags )
+ __field( int, order )
+ __field( unsigned short, memcg_id )
),
TP_fast_assign(
- __entry->order = order;
__entry->gfp_flags = (__force unsigned long)gfp_flags;
+ __entry->order = order;
+ __entry->memcg_id = memcg_id;
),
- TP_printk("order=%d gfp_flags=%s",
+ TP_printk("order=%d gfp_flags=%s memcg_id=%u",
__entry->order,
- show_gfp_flags(__entry->gfp_flags))
+ show_gfp_flags(__entry->gfp_flags),
+ __entry->memcg_id)
);
DEFINE_EVENT(mm_vmscan_direct_reclaim_begin_template, mm_vmscan_direct_reclaim_begin,
- TP_PROTO(int order, gfp_t gfp_flags),
+ TP_PROTO(gfp_t gfp_flags, int order, unsigned short memcg_id),
- TP_ARGS(order, gfp_flags)
+ TP_ARGS(gfp_flags, order, memcg_id)
);
#ifdef CONFIG_MEMCG
DEFINE_EVENT(mm_vmscan_direct_reclaim_begin_template, mm_vmscan_memcg_reclaim_begin,
- TP_PROTO(int order, gfp_t gfp_flags),
+ TP_PROTO(gfp_t gfp_flags, int order, unsigned short memcg_id),
- TP_ARGS(order, gfp_flags)
+ TP_ARGS(gfp_flags, order, memcg_id)
);
DEFINE_EVENT(mm_vmscan_direct_reclaim_begin_template, mm_vmscan_memcg_softlimit_reclaim_begin,
- TP_PROTO(int order, gfp_t gfp_flags),
+ TP_PROTO(gfp_t gfp_flags, int order, unsigned short memcg_id),
- TP_ARGS(order, gfp_flags)
+ TP_ARGS(gfp_flags, order, memcg_id)
);
#endif /* CONFIG_MEMCG */
DECLARE_EVENT_CLASS(mm_vmscan_direct_reclaim_end_template,
- TP_PROTO(unsigned long nr_reclaimed),
+ TP_PROTO(unsigned long nr_reclaimed, unsigned short memcg_id),
- TP_ARGS(nr_reclaimed),
+ TP_ARGS(nr_reclaimed, memcg_id),
TP_STRUCT__entry(
__field( unsigned long, nr_reclaimed )
+ __field( unsigned short, memcg_id )
),
TP_fast_assign(
__entry->nr_reclaimed = nr_reclaimed;
+ __entry->memcg_id = memcg_id;
),
- TP_printk("nr_reclaimed=%lu", __entry->nr_reclaimed)
+ TP_printk("nr_reclaimed=%lu memcg_id=%u",
+ __entry->nr_reclaimed,
+ __entry->memcg_id)
);
DEFINE_EVENT(mm_vmscan_direct_reclaim_end_template, mm_vmscan_direct_reclaim_end,
- TP_PROTO(unsigned long nr_reclaimed),
+ TP_PROTO(unsigned long nr_reclaimed, unsigned short memcg_id),
- TP_ARGS(nr_reclaimed)
+ TP_ARGS(nr_reclaimed, memcg_id)
);
#ifdef CONFIG_MEMCG
DEFINE_EVENT(mm_vmscan_direct_reclaim_end_template, mm_vmscan_memcg_reclaim_end,
- TP_PROTO(unsigned long nr_reclaimed),
+ TP_PROTO(unsigned long nr_reclaimed, unsigned short memcg_id),
- TP_ARGS(nr_reclaimed)
+ TP_ARGS(nr_reclaimed, memcg_id)
);
DEFINE_EVENT(mm_vmscan_direct_reclaim_end_template, mm_vmscan_memcg_softlimit_reclaim_end,
- TP_PROTO(unsigned long nr_reclaimed),
+ TP_PROTO(unsigned long nr_reclaimed, unsigned short memcg_id),
- TP_ARGS(nr_reclaimed)
+ TP_ARGS(nr_reclaimed, memcg_id)
);
#endif /* CONFIG_MEMCG */
@@ -208,31 +215,34 @@ TRACE_EVENT(mm_shrink_slab_start,
TP_STRUCT__entry(
__field(struct shrinker *, shr)
__field(void *, shrink)
- __field(int, nid)
__field(long, nr_objects_to_shrink)
__field(unsigned long, gfp_flags)
__field(unsigned long, cache_items)
__field(unsigned long long, delta)
__field(unsigned long, total_scan)
__field(int, priority)
+ __field(int, nid)
+ __field(unsigned short, memcg_id)
),
TP_fast_assign(
__entry->shr = shr;
__entry->shrink = shr->scan_objects;
- __entry->nid = sc->nid;
__entry->nr_objects_to_shrink = nr_objects_to_shrink;
__entry->gfp_flags = (__force unsigned long)sc->gfp_mask;
__entry->cache_items = cache_items;
__entry->delta = delta;
__entry->total_scan = total_scan;
__entry->priority = priority;
+ __entry->nid = sc->nid;
+ __entry->memcg_id = sc->memcg ? cgroup_id(sc->memcg->css.cgroup) : 0;
),
- TP_printk("%pS %p: nid: %d objects to shrink %ld gfp_flags %s cache items %ld delta %lld total_scan %ld priority %d",
+ TP_printk("%pS %p: nid: %d memcg_id: %u objects to shrink %ld gfp_flags %s cache items %ld delta %lld total_scan %ld priority %d",
__entry->shrink,
__entry->shr,
__entry->nid,
+ __entry->memcg_id,
__entry->nr_objects_to_shrink,
show_gfp_flags(__entry->gfp_flags),
__entry->cache_items,
@@ -242,36 +252,39 @@ TRACE_EVENT(mm_shrink_slab_start,
);
TRACE_EVENT(mm_shrink_slab_end,
- TP_PROTO(struct shrinker *shr, int nid, int shrinker_retval,
+ TP_PROTO(struct shrinker *shr, struct shrink_control *sc, int shrinker_retval,
long unused_scan_cnt, long new_scan_cnt, long total_scan),
- TP_ARGS(shr, nid, shrinker_retval, unused_scan_cnt, new_scan_cnt,
+ TP_ARGS(shr, sc, shrinker_retval, unused_scan_cnt, new_scan_cnt,
total_scan),
TP_STRUCT__entry(
__field(struct shrinker *, shr)
- __field(int, nid)
__field(void *, shrink)
__field(long, unused_scan)
__field(long, new_scan)
- __field(int, retval)
__field(long, total_scan)
+ __field(int, nid)
+ __field(int, retval)
+ __field(unsigned short, memcg_id)
),
TP_fast_assign(
__entry->shr = shr;
- __entry->nid = nid;
__entry->shrink = shr->scan_objects;
__entry->unused_scan = unused_scan_cnt;
__entry->new_scan = new_scan_cnt;
- __entry->retval = shrinker_retval;
__entry->total_scan = total_scan;
+ __entry->nid = sc->nid;
+ __entry->retval = shrinker_retval;
+ __entry->memcg_id = cgroup_id(sc->memcg->css.cgroup);
),
- TP_printk("%pS %p: nid: %d unused scan count %ld new scan count %ld total_scan %ld last shrinker return val %d",
+ TP_printk("%pS %p: nid: %d memcg_id: %u unused scan count %ld new scan count %ld total_scan %ld last shrinker return val %d",
__entry->shrink,
__entry->shr,
__entry->nid,
+ __entry->memcg_id,
__entry->unused_scan,
__entry->new_scan,
__entry->total_scan,
@@ -504,9 +517,9 @@ TRACE_EVENT(mm_vmscan_node_reclaim_begin,
DEFINE_EVENT(mm_vmscan_direct_reclaim_end_template, mm_vmscan_node_reclaim_end,
- TP_PROTO(unsigned long nr_reclaimed),
+ TP_PROTO(unsigned long nr_reclaimed, unsigned short memcg_id),
- TP_ARGS(nr_reclaimed)
+ TP_ARGS(nr_reclaimed, memcg_id)
);
TRACE_EVENT(mm_vmscan_throttled,
diff --git a/mm/shrinker.c b/mm/shrinker.c
index 4a93fd433689a..e3b894c20bec8 100644
--- a/mm/shrinker.c
+++ b/mm/shrinker.c
@@ -461,7 +461,7 @@ static unsigned long do_shrink_slab(struct shrink_control *shrinkctl,
*/
new_nr = add_nr_deferred(next_deferred, shrinker, shrinkctl);
- trace_mm_shrink_slab_end(shrinker, shrinkctl->nid, freed, nr, new_nr, total_scan);
+ trace_mm_shrink_slab_end(shrinker, shrinkctl, freed, nr, new_nr, total_scan);
return freed;
}
diff --git a/mm/vmscan.c b/mm/vmscan.c
index b2fc8b626d3df..3ac9f45461795 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -6642,11 +6642,11 @@ unsigned long try_to_free_pages(struct zonelist *zonelist, int order,
return 1;
set_task_reclaim_state(current, &sc.reclaim_state);
- trace_mm_vmscan_direct_reclaim_begin(order, sc.gfp_mask);
+ trace_mm_vmscan_direct_reclaim_begin(sc.gfp_mask, order, 0);
nr_reclaimed = do_try_to_free_pages(zonelist, &sc);
- trace_mm_vmscan_direct_reclaim_end(nr_reclaimed);
+ trace_mm_vmscan_direct_reclaim_end(nr_reclaimed, 0);
set_task_reclaim_state(current, NULL);
return nr_reclaimed;
@@ -6675,8 +6675,9 @@ unsigned long mem_cgroup_shrink_node(struct mem_cgroup *memcg,
sc.gfp_mask = (gfp_mask & GFP_RECLAIM_MASK) |
(GFP_HIGHUSER_MOVABLE & ~GFP_RECLAIM_MASK);
- trace_mm_vmscan_memcg_softlimit_reclaim_begin(sc.order,
- sc.gfp_mask);
+ trace_mm_vmscan_memcg_softlimit_reclaim_begin(sc.gfp_mask,
+ sc.order,
+ cgroup_id(memcg->css.cgroup));
/*
* NOTE: Although we can get the priority field, using it
@@ -6687,7 +6688,7 @@ unsigned long mem_cgroup_shrink_node(struct mem_cgroup *memcg,
*/
shrink_lruvec(lruvec, &sc);
- trace_mm_vmscan_memcg_softlimit_reclaim_end(sc.nr_reclaimed);
+ trace_mm_vmscan_memcg_softlimit_reclaim_end(sc.nr_reclaimed, cgroup_id(memcg->css.cgroup));
*nr_scanned = sc.nr_scanned;
@@ -6723,13 +6724,13 @@ unsigned long try_to_free_mem_cgroup_pages(struct mem_cgroup *memcg,
struct zonelist *zonelist = node_zonelist(numa_node_id(), sc.gfp_mask);
set_task_reclaim_state(current, &sc.reclaim_state);
- trace_mm_vmscan_memcg_reclaim_begin(0, sc.gfp_mask);
+ trace_mm_vmscan_memcg_reclaim_begin(sc.gfp_mask, 0, cgroup_id(memcg->css.cgroup));
noreclaim_flag = memalloc_noreclaim_save();
nr_reclaimed = do_try_to_free_pages(zonelist, &sc);
memalloc_noreclaim_restore(noreclaim_flag);
- trace_mm_vmscan_memcg_reclaim_end(nr_reclaimed);
+ trace_mm_vmscan_memcg_reclaim_end(nr_reclaimed, cgroup_id(memcg->css.cgroup));
set_task_reclaim_state(current, NULL);
return nr_reclaimed;
@@ -7675,7 +7676,7 @@ static unsigned long __node_reclaim(struct pglist_data *pgdat, gfp_t gfp_mask,
delayacct_freepages_end();
psi_memstall_leave(&pflags);
- trace_mm_vmscan_node_reclaim_end(sc->nr_reclaimed);
+ trace_mm_vmscan_node_reclaim_end(sc->nr_reclaimed, 0);
return sc->nr_reclaimed;
}
--
2.33.8
^ permalink raw reply related
* Re: [PATCH v4 7/7] kernel.h: drop trace_printk.h
From: Yury Norov @ 2026-01-05 16:36 UTC (permalink / raw)
To: Jani Nikula
Cc: Andy Shevchenko, Joel Fernandes, Steven Rostedt, Andrew Morton,
Masami Hiramatsu, Mathieu Desnoyers, Christophe Leroy,
Randy Dunlap, Ingo Molnar, Joonas Lahtinen, David Laight,
Petr Pavlu, Andi Shyti, Rodrigo Vivi, Tvrtko Ursulin,
Daniel Gomez, Greg Kroah-Hartman, Rafael J. Wysocki,
Danilo Krummrich, linux-kernel, intel-gfx, dri-devel,
linux-modules, linux-trace-kernel
In-Reply-To: <254c1096c3b892923dd12b07a8b80291b88c0e9b@intel.com>
On Mon, Jan 05, 2026 at 11:29:51AM +0200, Jani Nikula wrote:
> On Sat, 03 Jan 2026, Yury Norov <yury.norov@gmail.com> wrote:
> > On Sat, Jan 03, 2026 at 02:57:58PM +0200, Andy Shevchenko wrote:
> >> On Fri, Jan 02, 2026 at 07:50:59PM -0500, Joel Fernandes wrote:
> >> > On Mon, Dec 29, 2025 at 11:17:48AM -0500, Steven Rostedt wrote:
> >>
> >> ...
> >>
> >> > I use trace_printk() all the time for kernel, particularly RCU development.
> >> > One of the key usecases I have is dumping traces on panic (with panic on warn
> >> > and stop tracing on warn enabled). This is extremely useful since I can add
> >> > custom tracing and dump traces when rare conditions occur. I fixed several
> >> > bugs with this technique.
> >> >
> >> > I also recommend keeping it convenient to use.
> >>
> >> Okay, you know C, please share your opinion what header is the best to hold the
> >> trace_printk.h to be included.
> >
> > What if we include it on Makefile level, similarly to how W=1 works?
> >
> > make D=1 // trace_printk() is available
> > make D=0 // trace_printk() is not available
> > make // trace_printk() is not available
> >
> > Where D stands for debugging.
> >
> > D=1 may be a default setting if you prefer, but the most important is
> > that every compilation unit will have an access to debugging without
> > polluting core headers.
>
> You do realize this means recompiling everything when adding D=1 for
> debugging?
Yes sir I do.
It would be as simple (or hard) as building another arch:
make O=../build/linux-arm64
make O=../build/linux-x86_64
make D=1 W=1 O=../build/linux-x86_64-dev
If you're both developer and CI engineer in your company, you're likely
already doing something like that. If you're CI-only, there're no
changes for you. If you're a developer - yeah, you'd have to learn a
new flag.
The real problem of course is the status inflation. The fact that
defconfig enables CONFIG_EXPERT and CONFIG_DEBUG_KERNEL implies that
every random person who is able to do:
git clone && make && sudo make install
now assumed an expert kernel user and active developer. It is not
correct, and it leads to bloating kernel with dev-only features.
What we discuss here is a new marker for those real experts and
developers, I think. (In an hope that it will inflate not very fast.)
Thanks,
Yury
^ permalink raw reply
* Re: [PATCH v4 7/7] kernel.h: drop trace_printk.h
From: Steven Rostedt @ 2026-01-05 16:39 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Joel Fernandes, Andrew Morton, Yury Norov, Masami Hiramatsu,
Mathieu Desnoyers, Christophe Leroy, Randy Dunlap, Ingo Molnar,
Jani Nikula, Joonas Lahtinen, David Laight, Petr Pavlu,
Andi Shyti, Vivi Rodrigo, Tvrtko Ursulin, Daniel Gomez,
Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich,
linux-kernel@vger.kernel.org, intel-gfx@lists.freedesktop.org,
dri-devel@lists.freedesktop.org, linux-modules@vger.kernel.org,
linux-trace-kernel@vger.kernel.org
In-Reply-To: <aVmyZ0iXzTkNU86y@smile.fi.intel.com>
On Sun, 4 Jan 2026 02:20:55 +0200
Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote:
> >
> > I do not think it is necessary to move it.
>
> I'm not talking about move, I'm talking about the C 101 thingy. Any custom API
> should be included before use, otherwise compiler won't see it. Which header do
> you want to include to have this API being provided? Note, it's really bad
> situation right now with the header to be included implicitly via non-obvious
> or obscure path. The discussion moved as far as I see it towards the finding a
> good place for the trace_printk.h.
It's not a normal API. It's for debugging the kernel. Thus it should be
available everywhere without having to add a header. Hence, the best place
to include trace_printk.h, is in kernel.h.
I'm thinking that my proposed config option is the best solution now. For
those that do not care about debugging the kernel, you enable the
"HIDE_TRACE_PRINTK" config so that your builds will be "quicker". But for
everyone else, it will not slow down their workflow when they need to debug
code.
-- Steve
^ permalink raw reply
* Re: [PATCH v4 7/7] kernel.h: drop trace_printk.h
From: Steven Rostedt @ 2026-01-05 16:50 UTC (permalink / raw)
To: Yury Norov
Cc: Jani Nikula, Andy Shevchenko, Joel Fernandes, Andrew Morton,
Masami Hiramatsu, Mathieu Desnoyers, Christophe Leroy,
Randy Dunlap, Ingo Molnar, Joonas Lahtinen, David Laight,
Petr Pavlu, Andi Shyti, Rodrigo Vivi, Tvrtko Ursulin,
Daniel Gomez, Greg Kroah-Hartman, Rafael J. Wysocki,
Danilo Krummrich, linux-kernel, intel-gfx, dri-devel,
linux-modules, linux-trace-kernel
In-Reply-To: <aVvoe5fQN3EUtEAJ@yury>
On Mon, 5 Jan 2026 11:36:11 -0500
Yury Norov <yury.norov@gmail.com> wrote:
> > You do realize this means recompiling everything when adding D=1 for
> > debugging?
>
> Yes sir I do.
>
> It would be as simple (or hard) as building another arch:
>
> make O=../build/linux-arm64
> make O=../build/linux-x86_64
> make D=1 W=1 O=../build/linux-x86_64-dev
>
> If you're both developer and CI engineer in your company, you're likely
> already doing something like that. If you're CI-only, there're no
> changes for you. If you're a developer - yeah, you'd have to learn a
> new flag.
I'm saying this right now.
Hard-nacked-by: Steven Rostedt <rostedt@goodmis.org>
Why do you want to burden developers?
>
> The real problem of course is the status inflation. The fact that
> defconfig enables CONFIG_EXPERT and CONFIG_DEBUG_KERNEL implies that
> every random person who is able to do:
>
> git clone && make && sudo make install
>
> now assumed an expert kernel user and active developer. It is not
> correct, and it leads to bloating kernel with dev-only features.
>
> What we discuss here is a new marker for those real experts and
> developers, I think. (In an hope that it will inflate not very fast.)
This is a generic feature that helps all developers. The ones spending the
most time in maintaining the kernel.
Add the config I mentioned:
config HIDE_TRACE_PRINTK
depends on TRACING
help
trace_printk() is an extremely powerful utility to debug and develop
kernel code. It is defined in kernel.h so that it can be easily accessed
during development or having to debug existing code.
But trace_printk() is not to be included in the final result, and having
it in kernel.h during normal builds where the builder has no plans of
debugging the kernel causes wasted cycles and time in compiling the kernel.
By saying yes here, the include of trace_printk() macros will be hidden
from kernel.h and help speed up the compile.
If you do not plan on debugging this kernel, say Y
It is default 'n' as the normal person building their own kernel likely
wants to debug it. Once you set this to 'y' then you get your "fast" builds.
Then in kernel.h have:
#ifndef CONFIG_HIDE_TRACE_PRINTK
# include <linux/trace_printk.h>
#endif
-- Steve
^ permalink raw reply
* Re: [PATCH v4 7/7] kernel.h: drop trace_printk.h
From: Joel Fernandes @ 2026-01-05 17:11 UTC (permalink / raw)
To: Steven Rostedt, Andy Shevchenko
Cc: Andrew Morton, Yury Norov, Masami Hiramatsu, Mathieu Desnoyers,
Christophe Leroy, Randy Dunlap, Ingo Molnar, Jani Nikula,
Joonas Lahtinen, David Laight, Petr Pavlu, Andi Shyti,
Vivi Rodrigo, Tvrtko Ursulin, Daniel Gomez, Greg Kroah-Hartman,
Rafael J. Wysocki, Danilo Krummrich, linux-kernel@vger.kernel.org,
intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
linux-modules@vger.kernel.org, linux-trace-kernel@vger.kernel.org
In-Reply-To: <20260105113902.6bdfcfa8@gandalf.local.home>
On 1/5/2026 11:39 AM, Steven Rostedt wrote:
> On Sun, 4 Jan 2026 02:20:55 +0200
> Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote:
>
>>>
>>> I do not think it is necessary to move it.
>>
>> I'm not talking about move, I'm talking about the C 101 thingy. Any custom API
>> should be included before use, otherwise compiler won't see it. Which header do
>> you want to include to have this API being provided? Note, it's really bad
>> situation right now with the header to be included implicitly via non-obvious
>> or obscure path. The discussion moved as far as I see it towards the finding a
>> good place for the trace_printk.h.
>
> It's not a normal API. It's for debugging the kernel. Thus it should be
> available everywhere without having to add a header. Hence, the best place
> to include trace_printk.h, is in kernel.h.
>
> I'm thinking that my proposed config option is the best solution now. For
> those that do not care about debugging the kernel, you enable the
> "HIDE_TRACE_PRINTK" config so that your builds will be "quicker". But for
> everyone else, it will not slow down their workflow when they need to debug
> code.
100% agree. We do have people running custom configs for faster builds, so this
hide thing could be enabled there assuming those don't care about debug.
In other words, "If it aint broke, don't fix it".
- Joel
^ permalink raw reply
* Re: [PATCH v4 7/7] kernel.h: drop trace_printk.h
From: Andy Shevchenko @ 2026-01-05 18:02 UTC (permalink / raw)
To: Steven Rostedt
Cc: Joel Fernandes, Andrew Morton, Yury Norov, Masami Hiramatsu,
Mathieu Desnoyers, Christophe Leroy, Randy Dunlap, Ingo Molnar,
Jani Nikula, Joonas Lahtinen, David Laight, Petr Pavlu,
Andi Shyti, Vivi Rodrigo, Tvrtko Ursulin, Daniel Gomez,
Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich,
linux-kernel@vger.kernel.org, intel-gfx@lists.freedesktop.org,
dri-devel@lists.freedesktop.org, linux-modules@vger.kernel.org,
linux-trace-kernel@vger.kernel.org
In-Reply-To: <20260105113902.6bdfcfa8@gandalf.local.home>
On Mon, Jan 05, 2026 at 11:39:02AM -0500, Steven Rostedt wrote:
> On Sun, 4 Jan 2026 02:20:55 +0200
> Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote:
>
> > > I do not think it is necessary to move it.
> >
> > I'm not talking about move, I'm talking about the C 101 thingy. Any custom API
> > should be included before use, otherwise compiler won't see it. Which header do
> > you want to include to have this API being provided? Note, it's really bad
> > situation right now with the header to be included implicitly via non-obvious
> > or obscure path. The discussion moved as far as I see it towards the finding a
> > good place for the trace_printk.h.
>
> It's not a normal API. It's for debugging the kernel. Thus it should be
> available everywhere without having to add a header. Hence, the best place
> to include trace_printk.h, is in kernel.h.
With the above it sounds like you rather want to see it being included as
kconfig.h (to every single file). But I disagree on that approach, why do
we need this header to pollute every file even if I do not debug the thing?
But since the current state is kernel.h, the status quo is to keep it there
for now.
> I'm thinking that my proposed config option is the best solution now. For
> those that do not care about debugging the kernel, you enable the
> "HIDE_TRACE_PRINTK" config so that your builds will be "quicker". But for
> everyone else, it will not slow down their workflow when they need to debug
> code.
Maybe, to keep a status quo.
Seems for now the compromise is to have it split and be included back to
kernel.h and later we can decide if the option or other variants can give a
better granularity for people who are not lazy to remember and add a header if
they need to debug stuff.
Yury, I think in v5 you need to drop this patch, otherwise we won't move further.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v4 7/7] kernel.h: drop trace_printk.h
From: Yury Norov @ 2026-01-05 18:07 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Steven Rostedt, Joel Fernandes, Andrew Morton, Masami Hiramatsu,
Mathieu Desnoyers, Christophe Leroy, Randy Dunlap, Ingo Molnar,
Jani Nikula, Joonas Lahtinen, David Laight, Petr Pavlu,
Andi Shyti, Vivi Rodrigo, Tvrtko Ursulin, Daniel Gomez,
Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich,
linux-kernel@vger.kernel.org, intel-gfx@lists.freedesktop.org,
dri-devel@lists.freedesktop.org, linux-modules@vger.kernel.org,
linux-trace-kernel@vger.kernel.org
In-Reply-To: <aVv8vwtGFhssitxG@smile.fi.intel.com>
On Mon, Jan 05, 2026 at 08:02:39PM +0200, Andy Shevchenko wrote:
> On Mon, Jan 05, 2026 at 11:39:02AM -0500, Steven Rostedt wrote:
> > On Sun, 4 Jan 2026 02:20:55 +0200
> > Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote:
> >
> > > > I do not think it is necessary to move it.
> > >
> > > I'm not talking about move, I'm talking about the C 101 thingy. Any custom API
> > > should be included before use, otherwise compiler won't see it. Which header do
> > > you want to include to have this API being provided? Note, it's really bad
> > > situation right now with the header to be included implicitly via non-obvious
> > > or obscure path. The discussion moved as far as I see it towards the finding a
> > > good place for the trace_printk.h.
> >
> > It's not a normal API. It's for debugging the kernel. Thus it should be
> > available everywhere without having to add a header. Hence, the best place
> > to include trace_printk.h, is in kernel.h.
>
> With the above it sounds like you rather want to see it being included as
> kconfig.h (to every single file). But I disagree on that approach, why do
> we need this header to pollute every file even if I do not debug the thing?
>
> But since the current state is kernel.h, the status quo is to keep it there
> for now.
>
> > I'm thinking that my proposed config option is the best solution now. For
> > those that do not care about debugging the kernel, you enable the
> > "HIDE_TRACE_PRINTK" config so that your builds will be "quicker". But for
> > everyone else, it will not slow down their workflow when they need to debug
> > code.
>
> Maybe, to keep a status quo.
+1
> Seems for now the compromise is to have it split and be included back to
> kernel.h and later we can decide if the option or other variants can give a
> better granularity for people who are not lazy to remember and add a header if
> they need to debug stuff.
>
> Yury, I think in v5 you need to drop this patch, otherwise we won't move further.
Not sure we need v5 because the only change is dropping the last patch
in the series. But if you prefer - I can send v5.
^ permalink raw reply
* Re: [PATCH v4 7/7] kernel.h: drop trace_printk.h
From: Andy Shevchenko @ 2026-01-05 18:11 UTC (permalink / raw)
To: Yury Norov
Cc: Steven Rostedt, Joel Fernandes, Andrew Morton, Masami Hiramatsu,
Mathieu Desnoyers, Christophe Leroy, Randy Dunlap, Ingo Molnar,
Jani Nikula, Joonas Lahtinen, David Laight, Petr Pavlu,
Andi Shyti, Vivi Rodrigo, Tvrtko Ursulin, Daniel Gomez,
Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich,
linux-kernel@vger.kernel.org, intel-gfx@lists.freedesktop.org,
dri-devel@lists.freedesktop.org, linux-modules@vger.kernel.org,
linux-trace-kernel@vger.kernel.org
In-Reply-To: <aVv946dXQfOifz5O@yury>
On Mon, Jan 05, 2026 at 01:07:31PM -0500, Yury Norov wrote:
> On Mon, Jan 05, 2026 at 08:02:39PM +0200, Andy Shevchenko wrote:
> > On Mon, Jan 05, 2026 at 11:39:02AM -0500, Steven Rostedt wrote:
...
> > Yury, I think in v5 you need to drop this patch, otherwise we won't move further.
>
> Not sure we need v5 because the only change is dropping the last patch
> in the series. But if you prefer - I can send v5.
It depends on who is going to apply them. For me personally v5 is not needed,
but I think there were some tags given in v4? With that it might make some
sense to have a v5.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v4 7/7] kernel.h: drop trace_printk.h
From: Christophe Leroy (CS GROUP) @ 2026-01-05 18:21 UTC (permalink / raw)
To: Joel Fernandes, Steven Rostedt, Andy Shevchenko
Cc: Andrew Morton, Yury Norov, Masami Hiramatsu, Mathieu Desnoyers,
Randy Dunlap, Ingo Molnar, Jani Nikula, Joonas Lahtinen,
David Laight, Petr Pavlu, Andi Shyti, Vivi Rodrigo,
Tvrtko Ursulin, Daniel Gomez, Greg Kroah-Hartman,
Rafael J. Wysocki, Danilo Krummrich, linux-kernel@vger.kernel.org,
intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
linux-modules@vger.kernel.org, linux-trace-kernel@vger.kernel.org
In-Reply-To: <d642ef4c-145c-4b16-818d-153c8f2e3485@nvidia.com>
Le 05/01/2026 à 18:11, Joel Fernandes a écrit :
>
>
> On 1/5/2026 11:39 AM, Steven Rostedt wrote:
>> On Sun, 4 Jan 2026 02:20:55 +0200
>> Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote:
>>
>>>>
>>>> I do not think it is necessary to move it.
>>>
>>> I'm not talking about move, I'm talking about the C 101 thingy. Any custom API
>>> should be included before use, otherwise compiler won't see it. Which header do
>>> you want to include to have this API being provided? Note, it's really bad
>>> situation right now with the header to be included implicitly via non-obvious
>>> or obscure path. The discussion moved as far as I see it towards the finding a
>>> good place for the trace_printk.h.
>>
>> It's not a normal API. It's for debugging the kernel. Thus it should be
>> available everywhere without having to add a header. Hence, the best place
>> to include trace_printk.h, is in kernel.h.
>>
>> I'm thinking that my proposed config option is the best solution now. For
>> those that do not care about debugging the kernel, you enable the
>> "HIDE_TRACE_PRINTK" config so that your builds will be "quicker". But for
>> everyone else, it will not slow down their workflow when they need to debug
>> code.
>
> 100% agree. We do have people running custom configs for faster builds, so this
> hide thing could be enabled there assuming those don't care about debug.
>
> In other words, "If it aint broke, don't fix it".
But if I understand correctly, it would save 2% build time. That means
12 secondes on a 10 minutes build. Is it really worth it ?
Christophe
^ permalink raw reply
* Re: [PATCH v4 7/7] kernel.h: drop trace_printk.h
From: Jani Nikula @ 2026-01-05 18:30 UTC (permalink / raw)
To: Yury Norov
Cc: Andy Shevchenko, Joel Fernandes, Steven Rostedt, Andrew Morton,
Masami Hiramatsu, Mathieu Desnoyers, Christophe Leroy,
Randy Dunlap, Ingo Molnar, Joonas Lahtinen, David Laight,
Petr Pavlu, Andi Shyti, Rodrigo Vivi, Tvrtko Ursulin,
Daniel Gomez, Greg Kroah-Hartman, Rafael J. Wysocki,
Danilo Krummrich, linux-kernel, intel-gfx, dri-devel,
linux-modules, linux-trace-kernel
In-Reply-To: <aVvoe5fQN3EUtEAJ@yury>
On Mon, 05 Jan 2026, Yury Norov <yury.norov@gmail.com> wrote:
> On Mon, Jan 05, 2026 at 11:29:51AM +0200, Jani Nikula wrote:
>> On Sat, 03 Jan 2026, Yury Norov <yury.norov@gmail.com> wrote:
>> > On Sat, Jan 03, 2026 at 02:57:58PM +0200, Andy Shevchenko wrote:
>> >> On Fri, Jan 02, 2026 at 07:50:59PM -0500, Joel Fernandes wrote:
>> >> > On Mon, Dec 29, 2025 at 11:17:48AM -0500, Steven Rostedt wrote:
>> >>
>> >> ...
>> >>
>> >> > I use trace_printk() all the time for kernel, particularly RCU development.
>> >> > One of the key usecases I have is dumping traces on panic (with panic on warn
>> >> > and stop tracing on warn enabled). This is extremely useful since I can add
>> >> > custom tracing and dump traces when rare conditions occur. I fixed several
>> >> > bugs with this technique.
>> >> >
>> >> > I also recommend keeping it convenient to use.
>> >>
>> >> Okay, you know C, please share your opinion what header is the best to hold the
>> >> trace_printk.h to be included.
>> >
>> > What if we include it on Makefile level, similarly to how W=1 works?
>> >
>> > make D=1 // trace_printk() is available
>> > make D=0 // trace_printk() is not available
>> > make // trace_printk() is not available
>> >
>> > Where D stands for debugging.
>> >
>> > D=1 may be a default setting if you prefer, but the most important is
>> > that every compilation unit will have an access to debugging without
>> > polluting core headers.
>>
>> You do realize this means recompiling everything when adding D=1 for
>> debugging?
>
> Yes sir I do.
>
> It would be as simple (or hard) as building another arch:
>
> make O=../build/linux-arm64
> make O=../build/linux-x86_64
> make D=1 W=1 O=../build/linux-x86_64-dev
>
> If you're both developer and CI engineer in your company, you're likely
> already doing something like that. If you're CI-only, there're no
> changes for you. If you're a developer - yeah, you'd have to learn a
> new flag.
Learn a new flag?
What I'm saying is, if you're doing regular builds as a developer, and
*then* realize you need trace_printk(), doing your suggested 'make D=1'
rebuilds *everything*. Not exactly something you want in the middle of
your development flow.
I'd *rather* manually add that #include where needed, and rebuild just
those files. I don't even feel very strongly about the whole thing,
other than the D=1 being the worst suggestion so far in the thread.
BR,
Jani.
>
> The real problem of course is the status inflation. The fact that
> defconfig enables CONFIG_EXPERT and CONFIG_DEBUG_KERNEL implies that
> every random person who is able to do:
>
> git clone && make && sudo make install
>
> now assumed an expert kernel user and active developer. It is not
> correct, and it leads to bloating kernel with dev-only features.
>
> What we discuss here is a new marker for those real experts and
> developers, I think. (In an hope that it will inflate not very fast.)
>
> Thanks,
> Yury
--
Jani Nikula, Intel
^ permalink raw reply
* Re: [PATCH v4 7/7] kernel.h: drop trace_printk.h
From: Joel Fernandes @ 2026-01-05 19:33 UTC (permalink / raw)
To: Christophe Leroy (CS GROUP), Steven Rostedt, Andy Shevchenko
Cc: Andrew Morton, Yury Norov, Masami Hiramatsu, Mathieu Desnoyers,
Randy Dunlap, Ingo Molnar, Jani Nikula, Joonas Lahtinen,
David Laight, Petr Pavlu, Andi Shyti, Vivi Rodrigo,
Tvrtko Ursulin, Daniel Gomez, Greg Kroah-Hartman,
Rafael J. Wysocki, Danilo Krummrich, linux-kernel@vger.kernel.org,
intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
linux-modules@vger.kernel.org, linux-trace-kernel@vger.kernel.org
In-Reply-To: <63a00906-a5c6-43de-82ce-328c8eaa7d3f@kernel.org>
On 1/5/2026 1:21 PM, Christophe Leroy (CS GROUP) wrote:
>
>
> Le 05/01/2026 à 18:11, Joel Fernandes a écrit :
>>
>>
>> On 1/5/2026 11:39 AM, Steven Rostedt wrote:
>>> On Sun, 4 Jan 2026 02:20:55 +0200
>>> Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote:
>>>
>>>>>
>>>>> I do not think it is necessary to move it.
>>>>
>>>> I'm not talking about move, I'm talking about the C 101 thingy. Any custom API
>>>> should be included before use, otherwise compiler won't see it. Which header do
>>>> you want to include to have this API being provided? Note, it's really bad
>>>> situation right now with the header to be included implicitly via non-obvious
>>>> or obscure path. The discussion moved as far as I see it towards the finding a
>>>> good place for the trace_printk.h.
>>>
>>> It's not a normal API. It's for debugging the kernel. Thus it should be
>>> available everywhere without having to add a header. Hence, the best place
>>> to include trace_printk.h, is in kernel.h.
>>>
>>> I'm thinking that my proposed config option is the best solution now. For
>>> those that do not care about debugging the kernel, you enable the
>>> "HIDE_TRACE_PRINTK" config so that your builds will be "quicker". But for
>>> everyone else, it will not slow down their workflow when they need to debug
>>> code.
>>
>> 100% agree. We do have people running custom configs for faster builds, so this
>> hide thing could be enabled there assuming those don't care about debug.
>>
>> In other words, "If it aint broke, don't fix it".
>
> But if I understand correctly, it would save 2% build time. That means 12
> secondes on a 10 minutes build. Is it really worth it ?
>
99% of my kernel builds are usually 90 seconds. I throw a lot of cores at it and
with ccache. I care more about trace_printk not being available than saving 2%.
But YMMV. I am sure there are people who care a lot about build time, but for me
it has not (yet) been a problem.
- Joel
^ permalink raw reply
* Re: [PATCH v4 7/7] kernel.h: drop trace_printk.h
From: Steven Rostedt @ 2026-01-05 20:04 UTC (permalink / raw)
To: Joel Fernandes
Cc: Christophe Leroy (CS GROUP), Andy Shevchenko, Andrew Morton,
Yury Norov, Masami Hiramatsu, Mathieu Desnoyers, Randy Dunlap,
Ingo Molnar, Jani Nikula, Joonas Lahtinen, David Laight,
Petr Pavlu, Andi Shyti, Vivi Rodrigo, Tvrtko Ursulin,
Daniel Gomez, Greg Kroah-Hartman, Rafael J. Wysocki,
Danilo Krummrich, linux-kernel@vger.kernel.org,
intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
linux-modules@vger.kernel.org, linux-trace-kernel@vger.kernel.org
In-Reply-To: <e171f94d-060b-448c-aab5-bafc01fea7fe@nvidia.com>
On Mon, 5 Jan 2026 14:33:35 -0500
Joel Fernandes <joelagnelf@nvidia.com> wrote:
> >>> I'm thinking that my proposed config option is the best solution now. For
> >>> those that do not care about debugging the kernel, you enable the
> >>> "HIDE_TRACE_PRINTK" config so that your builds will be "quicker". But for
> >>> everyone else, it will not slow down their workflow when they need to debug
> >>> code.
> >>
> >> 100% agree. We do have people running custom configs for faster builds, so this
> >> hide thing could be enabled there assuming those don't care about debug.
> >>
> >> In other words, "If it aint broke, don't fix it".
> >
> > But if I understand correctly, it would save 2% build time. That means 12
> > secondes on a 10 minutes build. Is it really worth it ?
> >
> 99% of my kernel builds are usually 90 seconds. I throw a lot of cores at it and
> with ccache. I care more about trace_printk not being available than saving 2%.
> But YMMV. I am sure there are people who care a lot about build time, but for me
> it has not (yet) been a problem.
I can see Linus enabling this. I don't think he uses trace_printk() to
debug the kernel, so improving his build times may be useful.
-- Steve
^ permalink raw reply
* Re: [PATCH v4 7/7] kernel.h: drop trace_printk.h
From: Joel Fernandes @ 2026-01-05 20:15 UTC (permalink / raw)
To: Steven Rostedt
Cc: Christophe Leroy (CS GROUP), Andy Shevchenko, Andrew Morton,
Yury Norov, Masami Hiramatsu, Mathieu Desnoyers, Randy Dunlap,
Ingo Molnar, Jani Nikula, Joonas Lahtinen, David Laight,
Petr Pavlu, Andi Shyti, Vivi Rodrigo, Tvrtko Ursulin,
Daniel Gomez, Greg Kroah-Hartman, Rafael J. Wysocki,
Danilo Krummrich, linux-kernel@vger.kernel.org,
intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
linux-modules@vger.kernel.org, linux-trace-kernel@vger.kernel.org
In-Reply-To: <20260105150453.127927c9@gandalf.local.home>
On 1/5/2026 3:04 PM, Steven Rostedt wrote:
> On Mon, 5 Jan 2026 14:33:35 -0500
> Joel Fernandes <joelagnelf@nvidia.com> wrote:
>
>>>>> I'm thinking that my proposed config option is the best solution now. For
>>>>> those that do not care about debugging the kernel, you enable the
>>>>> "HIDE_TRACE_PRINTK" config so that your builds will be "quicker". But for
>>>>> everyone else, it will not slow down their workflow when they need to debug
>>>>> code.
>>>>
>>>> 100% agree. We do have people running custom configs for faster builds, so this
>>>> hide thing could be enabled there assuming those don't care about debug.
>>>>
>>>> In other words, "If it aint broke, don't fix it".
>>>
>>> But if I understand correctly, it would save 2% build time. That means 12
>>> secondes on a 10 minutes build. Is it really worth it ?
>>>
>> 99% of my kernel builds are usually 90 seconds. I throw a lot of cores at it and
>> with ccache. I care more about trace_printk not being available than saving 2%.
>> But YMMV. I am sure there are people who care a lot about build time, but for me
>> it has not (yet) been a problem.
>
> I can see Linus enabling this. I don't think he uses trace_printk() to
> debug the kernel, so improving his build times may be useful.
Sounds good to me. Making it an option sounds okay to me. Thanks.
^ permalink raw reply
* Re: [PATCH] arm64/mm: Fix annotated branch unbootable kernel
From: Will Deacon @ 2026-01-05 21:15 UTC (permalink / raw)
To: Breno Leitao
Cc: Catalin Marinas, Mark Rutland, Laura Abbott, linux-arm-kernel,
linux-kernel, linux-trace-kernel, Steven Rostedt,
Masami Hiramatsu, puranjay, usamaarif642, kernel-team, stable
In-Reply-To: <20251231-annotated-v1-1-9db1c0d03062@debian.org>
On Wed, Dec 31, 2025 at 04:44:05AM -0800, Breno Leitao wrote:
> The arm64 kernel doesn't boot with annotated branches
> (PROFILE_ANNOTATED_BRANCHES) enabled and CONFIG_DEBUG_VIRTUAL together.
>
> Bisecting it, I found that disabling branch profiling in arch/arm64/mm
> solved the problem. Narrowing down a bit further, I found that
> physaddr.c is the file that needs to have branch profiling disabled to
> get the machine to boot.
>
> I suspect that it might invoke some ftrace helper very early in the boot
> process and ftrace is still not enabled(!?).
>
> Disable branch profiling for physaddr.o to allow booting an arm64
> machine with CONFIG_PROFILE_ANNOTATED_BRANCHES and
> CONFIG_DEBUG_VIRTUAL together.
>
> Cc: stable@vger.kernel.org
> Fixes: ec6d06efb0bac ("arm64: Add support for CONFIG_DEBUG_VIRTUAL")
> Signed-off-by: Breno Leitao <leitao@debian.org>
> ---
> Another approach is to disable profiling on all arch/arm64 code, similarly to
> x86, where DISABLE_BRANCH_PROFILING is called for all arch/x86 code. See
> commit 2cbb20b008dba ("tracing: Disable branch profiling in noinstr
> code").
Yes, let's start with arch/arm64/. We know that's safe and then if
somebody wants to make it finer-grained, it's on them to figure out a
way to do it without playing whack-a-mole.
Will
^ permalink raw reply
* Re: [BUG/RFC 1/2] arm64/ftrace,bpf: Fix partial regs after bpf_prog_run
From: Steven Rostedt @ 2026-01-05 21:22 UTC (permalink / raw)
To: Masami Hiramatsu (Google)
Cc: Jiri Olsa, Will Deacon, Peter Zijlstra, bpf, linux-trace-kernel,
linux-arm-kernel, x86, Yonghong Song, Song Liu, Andrii Nakryiko,
Mark Rutland, Mahe Tardy
In-Reply-To: <20260104223415.0a31f423c861c0b651de966b@kernel.org>
On Sun, 4 Jan 2026 22:34:15 +0900
Masami Hiramatsu (Google) <mhiramat@kernel.org> wrote:
> > This looks a bit grotty to me and presumably other architectures would
> > need similar treatement. Wouldn't it be cleaner to reuse the existing
> > API instead? For example, by calling ftrace_regs_set_instruction_pointer()
> > and ftrace_regs_set_return_value() to update the relevant registers from
> > the core code?
>
> I agreed with using the generic APIs. Also, ftrace_partial_regs_fix() is
> not self-explained. Maybe ftrace_regs_set_by_regs()?
Or perhaps: ftrace_partial_regs_update() where you call it if you need to
update the regs.
/*
* ftrace_partial_regs_update - update the original ftrace_regs from regs
* @fregs: The ftrace_regs to update from @regs
* @regs: The partial regs from ftrace_partial_regs() that was updated
*
* Some architectures have the partial regs living in the ftrace_regs
* structure, whereas other architectures need to make a different copy
* of the @regs. If a partial @regs is retrieved by ftrace_partial_regs() and
* if the code using @regs updates a field (like the instruction pointer or
* stack pointer) it may need to propagate that change to the original @fregs
* it retrieved the partial @regs from. Use this function to guarantee that
* update happens.
*/
static __always_inline void
ftrace_partial_regs_update(const struct ftrace_regs *fregs, struct pt_regs *regs) {
struct __arch_ftrace_regs *afregs = arch_ftrace_regs(fregs);
if (afregs->pc != regs->pc) {
afregs->pc = regs->pc;
afregs->regs[0] = regs->regs[0];
}
}
-- Steve
^ permalink raw reply
* Re: [PATCH v1 1/4] tools/rtla: Consolidate nr_cpus usage across all tools
From: Crystal Wood @ 2026-01-05 22:24 UTC (permalink / raw)
To: Tomas Glozar, Costa Shulyupin
Cc: Steven Rostedt, Wander Lairson Costa, Ivan Pravdin, John Kacur,
Tiezhu Yang, linux-trace-kernel, linux-kernel, bpf
In-Reply-To: <CAP4=nvSr=Wz--CJgJ9kmXfB3r3uNYnt9bJt-_bCigH--rbbx2A@mail.gmail.com>
On Wed, 2025-12-17 at 10:06 +0100, Tomas Glozar wrote:
> út 16. 12. 2025 v 15:41 odesílatel Tomas Glozar <tglozar@redhat.com> napsal:
> > Since commit 2f3172f9dd58c ("tools/rtla: Consolidate code between
> > osnoise/timerlat and hist/top") that was merged into 6.18, common.h
> > includes timerlat_u.h. Your change thus causes a double include of
> > timerlat_u.h, leading to a build error:
> >
> > In file included from src/timerlat_u.c:20:
> > src/timerlat_u.h:6:8: error: redefinition of ‘struct timerlat_u_params’
> > 6 | struct timerlat_u_params {
> > | ^~~~~~~~~~~~~~~~~
> > In file included from src/common.h:5,
> > from src/timerlat_u.c:19:
> > src/timerlat_u.h:6:8: note: originally defined here
> > 6 | struct timerlat_u_params {
> > | ^~~~~~~~~~~~~~~~~
> >
> > Please rebase your patchset and fix this so that timerlat_u.h is only
> > included once.
> >
>
> Correction: the base of the patchset has nothing to do with this. It
> is the C standard, from C23 (default in GCC 15), redefinition of
> structs is allowed [1], so this error doesn't exist. In earlier
> standards, this is not allowed.
>
> [1] https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2863.pdf
Regardless of how permissive the language might be getting in this case,
we should have #pragma once on all of the headers to avoid this sort of
problem.
-Crystal
^ permalink raw reply
* Re: [PATCH v3 1/2] mm: vmscan: add cgroup IDs to vmscan tracepoints
From: Shakeel Butt @ 2026-01-05 22:46 UTC (permalink / raw)
To: Thomas Ballasi; +Cc: akpm, linux-mm, linux-trace-kernel, mhiramat, rostedt
In-Reply-To: <20260105160423.23708-2-tballasi@linux.microsoft.com>
On Mon, Jan 05, 2026 at 08:04:22AM -0800, Thomas Ballasi wrote:
> Memory reclaim events are currently difficult to attribute to
> specific cgroups, making debugging memory pressure issues
> challenging. This patch adds memory cgroup ID (memcg_id) to key
> vmscan tracepoints to enable better correlation and analysis.
>
> For operations not associated with a specific cgroup, the field
> is defaulted to 0.
>
> Signed-off-by: Thomas Ballasi <tballasi@linux.microsoft.com>
Couple of comments:
1. memcg_id is u64 but the patch is using 'unsigned short'.
2. I would prefer memcg pointer be passed in tracepoint and then in
trace header file cgroup_id() be used similar to other users in
include/trace/events/ folder.
Orthogonally I am cleaning up memcg id usage and after that cleanup,
mem_cgroup_id() would be preferred way to get the ID. No need to do
anything now as I will cleanup this usage later as well.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox