public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Arnaldo Carvalho de Melo <acme@kernel.org>
To: Tomas Glozar <tglozar@redhat.com>
Cc: Steven Rostedt <rostedt@goodmis.org>,
	linux-trace-kernel@vger.kernel.org, linux-kernel@vger.kernel.org,
	John Kacur <jkacur@redhat.com>,
	Luis Goncalves <lgoncalv@redhat.com>, Chang Yin <cyin@redhat.com>,
	Costa Shulyupin <costa.shul@redhat.com>
Subject: Re: [PATCH 0/8] rtla/timerlat: Support actions on threshold and on end
Date: Wed, 11 Jun 2025 11:46:32 -0300	[thread overview]
Message-ID: <aEmWyPqQw2Ly7Jlu@x1> (raw)
In-Reply-To: <20250611135644.219127-1-tglozar@redhat.com>

On Wed, Jun 11, 2025 at 03:56:36PM +0200, Tomas Glozar wrote:
> This series adds a feature that allows to user to specify certain
> kinds of "actions" to be executed at one of two places in the rtla
> measurement: when tracing is stopped on latency threshold, and at the
> end of tracing.
 
> Two new options are added: -A/--on-threshold, and -N/--on-end, taking
> the action as an argument. For example:

I wouldn't add -A and -N, leaving just the long options, as it documents
scripts (and we should have autocomplete as well), leaving the one
letter options for things that are used super frequently, which could be
these new options, after a while, time will tell :-)

But I see that "A"ction connection, and since you show it is used
multiple times in a single command line, maybe its warranted the
one-letter option.
 
> $ rtla timerlat hist -T 10 -A shell,command="echo Threshold" \
> -N shell,command="echo Tracing stopped"
 
> will print "Threshold" if a thread latency higher than 10 microseconds
> is reached, and "Tracing stopped" always at the end.
 
> The list of possible actions is extensible and is covered in
> the commit messages. Later, a documentation patch series will be sent
> with clear explanation of every action and its syntax.

I think having the documentation together with the new options is
desirable.
 
> Notably, a special action "continue" resumes tracing. For example:
 
> $ rtla timerlat hist -T 100 -A shell,command="echo Threshold" \
> -A continue -d 10s

so --on-threshold ends up being a list of things to do when the
threshold is hit?
 
> will print "Threshold" as many times as tracing is stopped after
> thread latency reaches 100us.

> The feature was inspired by a case where collecting perf data on rtla
> latency overflow was required, which can be done by sending a signal
> to the perf process.
 
> Example of this with Intel PT aux buffer:
 
> $ perf record --cpu 0 -e intel_pt// -S -- rtla timerlat top -q -T 100 \
> -c 0 -A signal,pid=parent,num=12 -A continue
 
> In general, the feature is aiming to allow integration with external
> tooling. To implement even more flexibility, passing context to the
> shell through environmental variables, or even an entire scripting
> language with access to the rtla internals can be implemented if
> needed.

That is an interesting example of cross-tool integration using existing
mechanisms for detecting special events and asking for hardware tracing
snapshots, good stuff!

At some point we need to have this signalling to not involve userspace,
shortcircuiting the snapshot request closer to the event of interest,
inside the kernel.

- Arnaldo
 
> Tomas Glozar (8):
>   rtla/timerlat: Introduce enum timerlat_tracing_mode
>   rtla/timerlat: Add action on threshold feature
>   rtla/timerlat_bpf: Allow resuming tracing
>   rtla/timerlat: Add continue action
>   rtla/timerlat: Add action on end feature
>   rtla/tests: Check rtla output with grep
>   rtla/tests: Add tests for actions
>   rtla/tests: Limit duration to maximum of 10s
> 
>  tools/tracing/rtla/src/Build           |   1 +
>  tools/tracing/rtla/src/actions.c       | 260 +++++++++++++++++++++++++
>  tools/tracing/rtla/src/actions.h       |  52 +++++
>  tools/tracing/rtla/src/timerlat.bpf.c  |  13 +-
>  tools/tracing/rtla/src/timerlat.c      |  24 ++-
>  tools/tracing/rtla/src/timerlat.h      |  24 ++-
>  tools/tracing/rtla/src/timerlat_bpf.c  |  13 ++
>  tools/tracing/rtla/src/timerlat_bpf.h  |   3 +
>  tools/tracing/rtla/src/timerlat_hist.c | 145 ++++++++++----
>  tools/tracing/rtla/src/timerlat_top.c  | 167 ++++++++++------
>  tools/tracing/rtla/tests/engine.sh     |  21 +-
>  tools/tracing/rtla/tests/hwnoise.t     |   8 +-
>  tools/tracing/rtla/tests/osnoise.t     |   4 +-
>  tools/tracing/rtla/tests/timerlat.t    |  36 +++-
>  14 files changed, 652 insertions(+), 119 deletions(-)
>  create mode 100644 tools/tracing/rtla/src/actions.c
>  create mode 100644 tools/tracing/rtla/src/actions.h
> 
> -- 
> 2.49.0

  parent reply	other threads:[~2025-06-11 14:46 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-06-11 13:56 [PATCH 0/8] rtla/timerlat: Support actions on threshold and on end Tomas Glozar
2025-06-11 13:56 ` [PATCH 1/8] rtla/timerlat: Introduce enum timerlat_tracing_mode Tomas Glozar
2025-06-11 13:56 ` [PATCH 2/8] rtla/timerlat: Add action on threshold feature Tomas Glozar
2025-08-03 11:08   ` Costa Shulyupin
2025-08-04 11:04     ` Tomas Glozar
2025-06-11 13:56 ` [PATCH 3/8] rtla/timerlat_bpf: Allow resuming tracing Tomas Glozar
2025-06-11 13:56 ` [PATCH 4/8] rtla/timerlat: Add continue action Tomas Glozar
2025-06-11 13:56 ` [PATCH 5/8] rtla/timerlat: Add action on end feature Tomas Glozar
2025-06-11 13:56 ` [PATCH 6/8] rtla/tests: Check rtla output with grep Tomas Glozar
2025-06-11 13:56 ` [PATCH 7/8] rtla/tests: Add tests for actions Tomas Glozar
2025-06-11 13:56 ` [PATCH 8/8] rtla/tests: Limit duration to maximum of 10s Tomas Glozar
2025-06-11 14:46 ` Arnaldo Carvalho de Melo [this message]
2025-06-23 14:15   ` [PATCH 0/8] rtla/timerlat: Support actions on threshold and on end Tomas Glozar

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=aEmWyPqQw2Ly7Jlu@x1 \
    --to=acme@kernel.org \
    --cc=costa.shul@redhat.com \
    --cc=cyin@redhat.com \
    --cc=jkacur@redhat.com \
    --cc=lgoncalv@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-trace-kernel@vger.kernel.org \
    --cc=rostedt@goodmis.org \
    --cc=tglozar@redhat.com \
    /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