From nobody Sat Feb 7 14:52:36 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id EF8B035DD14 for ; Tue, 27 Jan 2026 15:06:07 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769526368; cv=none; b=e4R7g9xOlnBA2hKL+4Gl5E2ISdRwlaZPh9av7E2nsKxk+/E8Z+RI2UsH/wE99G8KSGR96lbA0BfIDdAbeYzakTSRF4IHT9L1fMq1il46X+Lnb/v4nFW++JCqbpWW5sMmaCU27cfJ/cNwT+48EoaBympkFV7/vgP3syRk/Rj9rJ0= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769526368; c=relaxed/simple; bh=bicGd8d3hH1wHh88x65zy3nXf1AGVk/iW2GEnB43qAw=; h=Message-ID:Date:From:To:Cc:Subject:References:MIME-Version: Content-Type; b=I2IKLbxvufgDmexfGxPzEvuqbshonX3LVq/pOG/wgBBaeRzycqqOc2eL+ZR2O6iGPpGy7nuGrPOyVAv5sOZbIX4QmU8MNQMG4mihI+xqzMp7Q/CTgJKc4lAPW8Amf2TucilyaGz9P3ghyixe6GeRk33IIRwkc3woYhgWHa/gaZ0= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=fWlhPFAY; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="fWlhPFAY" Received: by smtp.kernel.org (Postfix) with ESMTPSA id D2239C116C6; Tue, 27 Jan 2026 15:06:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1769526367; bh=bicGd8d3hH1wHh88x65zy3nXf1AGVk/iW2GEnB43qAw=; h=Date:From:To:Cc:Subject:References:From; b=fWlhPFAYf4mRdbiQtCh0AsNtCG757aqfrDi1d7BnTVVlutLS0dpalRrP2qgyxOBms jOWpwrCxUJQ06UqMQJgB/e7QXuVcUaAAYMUc0EwSg16w05QWwl0/8mnJgY5QnFLpWj 3SQO2via/kGVBsap5fmWIHnBHhk8tvBVvZPWalvcZnHWaL8y4LKa06wib5KFzRnbSc vKedaDBfZzvjJXOI6tABfK70nBgzQG24UYi14cU3ei/2JmebFMoc3c5H37ZwgGXsSk AWmVC1r72enIXpZGPh1qqw7HNKOLLMZoDkmH4iwAtNopz1bmRaBwuQPU2q6D3Vw3RA d+1O9xTyDUQ7Q== Received: from rostedt by gandalf with local (Exim 4.99.1) (envelope-from ) id 1vkkdx-00000000Lh1-3CNp; Tue, 27 Jan 2026 10:06:13 -0500 Message-ID: <20260127150613.609056092@kernel.org> User-Agent: quilt/0.68 Date: Tue, 27 Jan 2026 10:06:09 -0500 From: Steven Rostedt To: linux-kernel@vger.kernel.org Cc: Masami Hiramatsu , Mark Rutland , Mathieu Desnoyers , Andrew Morton , Tom Zanussi Subject: [for-next][PATCH 14/15] tracing: Up the hist stacktrace size from 16 to 31 References: <20260127150555.840066272@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Steven Rostedt 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=3Dcommon_stacktrace:vals=3Dhitcount 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 =3D 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) >=3D STR_VAR_LEN_= MAX); Change that from ">=3D" to just ">", as now they are equal. Cc: Masami Hiramatsu Cc: Mathieu Desnoyers Link: https://patch.msgid.link/20260123105415.2be26bf4@gandalf.local.home Reviewed-by: Tom Zanussi Signed-off-by: Steven Rostedt (Google) --- 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 { =20 #define FAULT_STRING "(fault)" =20 -#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 =20 diff --git a/kernel/trace/trace_events_hist.c b/kernel/trace/trace_events_h= ist.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; =20 /* Make sure stacktrace can fit in the string variable length */ - BUILD_BUG_ON((HIST_STACKTRACE_DEPTH + 1) * sizeof(long) >=3D STR_VAR_LEN_= MAX); + BUILD_BUG_ON((HIST_STACKTRACE_DEPTH + 1) * sizeof(long) > STR_VAR_LEN_MAX= ); =20 for (i =3D 0, j =3D field_var_str_start; i < n_field_vars; i++) { struct field_var *field_var =3D field_vars[i]; --=20 2.51.0