public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Steven Rostedt <rostedt@kernel.org>
To: linux-kernel@vger.kernel.org
Cc: Masami Hiramatsu <mhiramat@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Tom Zanussi <zanussi@kernel.org>
Subject: [for-next][PATCH 14/15] tracing: Up the hist stacktrace size from 16 to 31
Date: Tue, 27 Jan 2026 10:06:09 -0500	[thread overview]
Message-ID: <20260127150613.609056092@kernel.org> (raw)
In-Reply-To: 20260127150555.840066272@kernel.org

From: Steven Rostedt <rostedt@goodmis.org>

Recording stacktraces is very useful, but the size of 16 deep is very
restrictive. For example, in seeing where tasks schedule out in a non
running state, the following can be used:

 ~# cd /sys/kernel/tracing
 ~# echo 'hist:keys=common_stacktrace:vals=hitcount if prev_state & 3' > events/sched/sched_switch/trigger
 ~# cat events/sched/sched_switch/hist
[..]
{ common_stacktrace:
         __schedule+0xdc0/0x1860
         schedule+0x27/0xd0
         schedule_timeout+0xb5/0x100
         wait_for_completion+0x8a/0x140
         xfs_buf_iowait+0x20/0xd0 [xfs]
         xfs_buf_read_map+0x103/0x250 [xfs]
         xfs_trans_read_buf_map+0x161/0x310 [xfs]
         xfs_btree_read_buf_block+0xa0/0x120 [xfs]
         xfs_btree_lookup_get_block+0xa3/0x1e0 [xfs]
         xfs_btree_lookup+0xea/0x530 [xfs]
         xfs_alloc_fixup_trees+0x72/0x570 [xfs]
         xfs_alloc_ag_vextent_size+0x67f/0x800 [xfs]
         xfs_alloc_vextent_iterate_ags.constprop.0+0x52/0x230 [xfs]
         xfs_alloc_vextent_start_ag+0x9d/0x1b0 [xfs]
         xfs_bmap_btalloc+0x2af/0x680 [xfs]
         xfs_bmapi_allocate+0xdb/0x2c0 [xfs]
} hitcount:          1
[..]

The above stops at 16 functions where knowing more would be useful. As the
allocated storage for stacks is the same for strings, and that size is 256
bytes, there is a lot of space not being used for stacktraces.

 16 * 8 = 128

Up the size to 31 (it requires the last slot to be zero, so it can't be 32).

Also change the BUILD_BUG_ON() to allow the size of the stacktrace storage
to be equal to the max size. One slot is used to hold the number of
elements in the stack.

  BUILD_BUG_ON((HIST_STACKTRACE_DEPTH + 1) * sizeof(long) >= STR_VAR_LEN_MAX);

Change that from ">=" to just ">", as now they are equal.

Cc: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Link: https://patch.msgid.link/20260123105415.2be26bf4@gandalf.local.home
Reviewed-by: Tom Zanussi <zanussi@kernel.org>
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
---
 kernel/trace/trace.h             | 2 +-
 kernel/trace/trace_events_hist.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/kernel/trace/trace.h b/kernel/trace/trace.h
index 8888fc9335b6..69e7defba6c6 100644
--- a/kernel/trace/trace.h
+++ b/kernel/trace/trace.h
@@ -128,7 +128,7 @@ enum trace_type {
 
 #define FAULT_STRING "(fault)"
 
-#define HIST_STACKTRACE_DEPTH	16
+#define HIST_STACKTRACE_DEPTH	31
 #define HIST_STACKTRACE_SIZE	(HIST_STACKTRACE_DEPTH * sizeof(unsigned long))
 #define HIST_STACKTRACE_SKIP	5
 
diff --git a/kernel/trace/trace_events_hist.c b/kernel/trace/trace_events_hist.c
index e245446a8cf7..0fc641461be5 100644
--- a/kernel/trace/trace_events_hist.c
+++ b/kernel/trace/trace_events_hist.c
@@ -3163,7 +3163,7 @@ static inline void __update_field_vars(struct tracing_map_elt *elt,
 	u64 var_val;
 
 	/* Make sure stacktrace can fit in the string variable length */
-	BUILD_BUG_ON((HIST_STACKTRACE_DEPTH + 1) * sizeof(long) >= STR_VAR_LEN_MAX);
+	BUILD_BUG_ON((HIST_STACKTRACE_DEPTH + 1) * sizeof(long) > STR_VAR_LEN_MAX);
 
 	for (i = 0, j = field_var_str_start; i < n_field_vars; i++) {
 		struct field_var *field_var = field_vars[i];
-- 
2.51.0



  parent reply	other threads:[~2026-01-27 15:06 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-01-27 15:05 [for-next][PATCH 00/15] tracing: Updates for 6.20 Steven Rostedt
2026-01-27 15:05 ` [for-next][PATCH 01/15] tracing: Properly process error handling in event_hist_trigger_parse() Steven Rostedt
2026-01-27 15:05 ` [for-next][PATCH 02/15] tracing: Remove redundant call to event_trigger_reset_filter() " Steven Rostedt
2026-01-27 15:05 ` [for-next][PATCH 03/15] tracing: Add bitmask-list option for human-readable bitmask display Steven Rostedt
2026-01-27 15:05 ` [for-next][PATCH 04/15] tracing: Replace use of system_wq with system_dfl_wq Steven Rostedt
2026-01-27 15:06 ` [for-next][PATCH 05/15] tracing: Add show_event_filters to expose active event filters Steven Rostedt
2026-01-27 15:06 ` [for-next][PATCH 06/15] tracing: Add show_event_triggers to expose active event triggers Steven Rostedt
2026-01-27 15:06 ` [for-next][PATCH 07/15] tracing: Check the return value of tracing_update_buffers() Steven Rostedt
2026-01-27 15:06 ` [for-next][PATCH 08/15] ring-buffer: Use a housekeeping CPU to wake up waiters Steven Rostedt
2026-01-27 15:06 ` [for-next][PATCH 09/15] tracing: Have show_event_trigger/filter format a bit more in columns Steven Rostedt
2026-01-27 15:06 ` [for-next][PATCH 10/15] ftrace: Introduce and use ENTRIES_PER_PAGE_GROUP macro Steven Rostedt
2026-01-27 15:06 ` [for-next][PATCH 11/15] tracing: Disable trace_printk buffer on warning too Steven Rostedt
2026-01-27 15:06 ` [for-next][PATCH 12/15] tracing: Have hist_debug show what function a field uses Steven Rostedt
2026-01-27 15:06 ` [for-next][PATCH 13/15] tracing: Remove notrace from trace_event_raw_event_synth() Steven Rostedt
2026-01-27 15:06 ` Steven Rostedt [this message]
2026-01-27 15:06 ` [for-next][PATCH 15/15] tracing: Remove duplicate ENABLE_EVENT_STR and DISABLE_EVENT_STR macros Steven Rostedt

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=20260127150613.609056092@kernel.org \
    --to=rostedt@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=mathieu.desnoyers@efficios.com \
    --cc=mhiramat@kernel.org \
    --cc=zanussi@kernel.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