From: Steven Rostedt <rostedt@goodmis.org>
To: Tomas Glozar <tglozar@redhat.com>
Cc: linux-trace-kernel@vger.kernel.org, linux-kernel@vger.kernel.org,
John Kacur <jkacur@redhat.com>,
Luis Goncalves <lgoncalv@redhat.com>,
Gabriele Monaco <gmonaco@redhat.com>
Subject: Re: [PATCH 0/5] rtla/timerlat: Stop on signal properly when overloaded
Date: Fri, 17 Jan 2025 10:29:24 -0500 [thread overview]
Message-ID: <20250117102924.690cb7c7@gandalf.local.home> (raw)
In-Reply-To: <CAP4=nvQpS20ubNspE0PPhiyWb3-ARV=gmQzFCA7WwAT8+rxMjg@mail.gmail.com>
On Fri, 17 Jan 2025 13:04:07 +0100
Tomas Glozar <tglozar@redhat.com> wrote:
> I was thinking of turning timerlat_hist_handler/timerlat_top_handler
> into a BPF program and having it executed right after the sample is
> created, e.g. by using the BPF perf interface to hook it to a
> tracepoint event. The histogram/counter would be stored in BPF maps,
> which would be merely copied over in the main loop. This is
> essentially how cyclictest does it, except in userspace. I expect this
> solution to have good performance, but the obvious downside is that it
> requires BPF. This is not a problem for us, but might be for other
> rtla users and we'd likely have to keep both implementations of sample
> processing in the code.
>
> Also, before even starting with that, it would be likely necessary to
> remove the duplicate code throughout timerlat/osnoise and test it
> properly, so we don't have to do the same code changes twice or four
> times.
We could also add kernel helpers to the code if it would help.
Hmm, the timerlat event could probably get access to a trigger to allow it
to do the work in the kernel like what the 'hist' triggers do. We can
extend on that.
The reason I haven't written a BPF program yet, is because when I feel
there's a useful operation that can be done, I just extend ftrace to do it
;-)
-- Steve
next prev parent reply other threads:[~2025-01-17 15:29 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-16 14:49 [PATCH 0/5] rtla/timerlat: Stop on signal properly when overloaded Tomas Glozar
2025-01-16 14:49 ` [PATCH 1/5] rtla: Add trace_instance_stop Tomas Glozar
2025-01-16 14:49 ` [PATCH 2/5] rtla/timerlat_hist: Stop timerlat tracer on signal Tomas Glozar
2025-01-16 14:49 ` [PATCH 3/5] rtla/timerlat_top: " Tomas Glozar
2025-01-17 0:56 ` Steven Rostedt
2025-01-17 7:13 ` Tomas Glozar
2025-01-17 10:50 ` Steven Rostedt
2025-01-16 14:49 ` [PATCH 4/5] rtla/timerlat_hist: Abort event processing on second signal Tomas Glozar
2025-01-16 14:49 ` [PATCH 5/5] rtla/timerlat_top: " Tomas Glozar
2025-01-17 0:57 ` Steven Rostedt
2025-01-17 6:58 ` Gabriele Monaco
2025-01-17 0:46 ` [PATCH 0/5] rtla/timerlat: Stop on signal properly when overloaded Steven Rostedt
2025-01-17 12:04 ` Tomas Glozar
2025-01-17 15:29 ` Steven Rostedt [this message]
2025-01-17 15:55 ` 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=20250117102924.690cb7c7@gandalf.local.home \
--to=rostedt@goodmis.org \
--cc=gmonaco@redhat.com \
--cc=jkacur@redhat.com \
--cc=lgoncalv@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-trace-kernel@vger.kernel.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