[PATCH v3] Documentation: trace: histogram-design: fix bracket, improve wording

From: Manuel Ebner

Date: Wed Sep 16 2026 - 07:56:11 EST


Remove needless ')' and put replace line with code block.

CC: Randy Dunlap <rdunlap@xxxxxxxxxxxxx>
Suggested-by: Steven Rostedt <rostedt@xxxxxxxxxxx>
Signed-off-by: Manuel Ebner <manuelebnerli@xxxxxxxxxxx>
---
@ Steven, sorry, I coudn't figure out how to implement your suggestions from [v2]

[v3]
remove line with similar content as code block.

[v2]
add paragraph and code block.
https://lore.kernel.org/all/20260903071105.714325-3-manuelebnerli@xxxxxxxxxxx/

[v1]
https://lore.kernel.org/all/20260902151032.706407-2-manuelebnerli@xxxxxxxxxxx/
---
Documentation/trace/histogram-design.rst | 12 +++++++++---
1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/Documentation/trace/histogram-design.rst b/Documentation/trace/histogram-design.rst
index 41a726cd3..5c5748928 100644
--- a/Documentation/trace/histogram-design.rst
+++ b/Documentation/trace/histogram-design.rst
@@ -876,9 +876,8 @@ next_pid field on this sched_switch event, we retrieve the
variables specified in the wakeup_latency() trace action, and use
them to generate a new wakeup_latency event into the trace stream.

-Note that the way the trace handlers such as wakeup_latency() (which
-could equivalently be written trace(wakeup_latency,$wakeup_lat,next_pid)
-are implemented, the parameters specified to the trace handler must be
+Note that the way the trace handlers such as wakeup_latency() are
+implemented, the parameters specified to the trace handler must be
variables. In this case, $wakeup_lat is obviously a variable, but
next_pid isn't, since it's just naming a field in the sched_switch
trace event. Since this is something that almost every trace() and
@@ -916,6 +915,13 @@ means it will be automatically converted into a field variable::
onmatch(sched.sched_waking).wakeup_latency($wakeup_lat,next_pid)' >>
/sys/kernel/tracing/events/sched/sched_switch/trigger

+Note that the above is the old way to trigger a synthetic event, whereas the
+newer way is preferred, which uses the trace() action handler::
+
+ # echo 'hist:keys=next_pid:wakeup_lat=common_timestamp.usecs-$ts0: \
+ onmatch(sched.sched_waking).trace(wakeup_latency,$wakeup_lat,next_pid)' >>
+ /sys/kernel/tracing/events/sched/sched_switch/trigger
+
The diagram for the sched_switch event is similar to previous examples
but shows the additional field_vars[] array for hist_data and shows
the linkages between the field_vars and the variables and references
--
2.55.0