| Message ID | 20190503143537.19752-1-tstoyanov@vmware.com (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | Documentation/trace: Add clarification how histogram onmatch works | expand |
On Fri, 3 May 2019 17:35:37 +0300 Tzvetomir Stoyanov <tstoyanov@vmware.com> wrote: > The current trace documentation, the section describing histogram's "onmatch" > is not straightforward enough about how this action is applied. It is not > clear what criteria are used to "match" both events. A short note is added, > describing what exactly is compared in order to match the events. Hi Tzvetomir, Thanks for sending this. Some minor tweaks below. > > Signed-off-by: Tzvetomir Stoyanov <tstoyanov@vmware.com> > --- > Documentation/trace/histogram.txt | 11 +++++++---- > 1 file changed, 7 insertions(+), 4 deletions(-) > > diff --git a/Documentation/trace/histogram.txt b/Documentation/trace/histogram.txt > index 7ffea6aa22e3..b75a75cfab8c 100644 > --- a/Documentation/trace/histogram.txt > +++ b/Documentation/trace/histogram.txt > @@ -1863,7 +1863,10 @@ hist trigger specification. > > The 'matching.event' specification is simply the fully qualified > event name of the event that matches the target event for the > - onmatch() functionality, in the form 'system.event_name'. > + onmatch() functionality, in the form 'system.event_name'. Histogram > + keys of both events are compared to find if events match. In case > + multiple histogram keys are used, they all must match in the specified > + order. I would reword that to be: In the case that multiple histogram keys are used, both events must have the same number of keys, and the keys must match in the same order. > > Finally, the number and type of variables/fields in the 'param > list' must match the number and types of the fields in the > @@ -1920,9 +1923,9 @@ hist trigger specification. > /sys/kernel/debug/tracing/events/sched/sched_waking/trigger > > Then, when the corresponding thread is actually scheduled onto the > - CPU by a sched_switch event, calculate the latency and use that > - along with another variable and an event field to generate a > - wakeup_latency synthetic event: > + CPU by a sched_switch event (saved_pid matches next_pid), calculate CPU by a sched_switch event (where the sched_waking key "saved_pid" matches the sched_switch key "next_pid"), Other than that, looks good. Could you send a v2 with the updates? Thanks! -- Steve > + the latency and use that along with another variable and an event field > + to generate a wakeup_latency synthetic event: > > # echo 'hist:keys=next_pid:wakeup_lat=common_timestamp.usecs-$ts0:\ > onmatch(sched.sched_waking).wakeup_latency($wakeup_lat,\
diff --git a/Documentation/trace/histogram.txt b/Documentation/trace/histogram.txt index 7ffea6aa22e3..b75a75cfab8c 100644 --- a/Documentation/trace/histogram.txt +++ b/Documentation/trace/histogram.txt @@ -1863,7 +1863,10 @@ hist trigger specification. The 'matching.event' specification is simply the fully qualified event name of the event that matches the target event for the - onmatch() functionality, in the form 'system.event_name'. + onmatch() functionality, in the form 'system.event_name'. Histogram + keys of both events are compared to find if events match. In case + multiple histogram keys are used, they all must match in the specified + order. Finally, the number and type of variables/fields in the 'param list' must match the number and types of the fields in the @@ -1920,9 +1923,9 @@ hist trigger specification. /sys/kernel/debug/tracing/events/sched/sched_waking/trigger Then, when the corresponding thread is actually scheduled onto the - CPU by a sched_switch event, calculate the latency and use that - along with another variable and an event field to generate a - wakeup_latency synthetic event: + CPU by a sched_switch event (saved_pid matches next_pid), calculate + the latency and use that along with another variable and an event field + to generate a wakeup_latency synthetic event: # echo 'hist:keys=next_pid:wakeup_lat=common_timestamp.usecs-$ts0:\ onmatch(sched.sched_waking).wakeup_latency($wakeup_lat,\
The current trace documentation, the section describing histogram's "onmatch" is not straightforward enough about how this action is applied. It is not clear what criteria are used to "match" both events. A short note is added, describing what exactly is compared in order to match the events. Signed-off-by: Tzvetomir Stoyanov <tstoyanov@vmware.com> --- Documentation/trace/histogram.txt | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-)