From: Jan Kiszka <jan.kiszka@siemens.com>
To: John Ogness <john.ogness@linutronix.de>
Cc: RT <linux-rt-users@vger.kernel.org>
Subject: Re: rtapp tracer
Date: Sat, 16 Sep 2023 16:49:23 +0530 [thread overview]
Message-ID: <12974db8-bc19-4149-8d15-219537f03cfc@siemens.com> (raw)
In-Reply-To: <87tts04yl6.fsf@jogness.linutronix.de>
Hi John,
On 11.09.23 19:10, John Ogness wrote:
> Hi Jan,
>
> On 2023-09-10, Jan Kiszka <jan.kiszka@siemens.com> wrote:
>> is your rtapp tracer [1] somewhere publicly available already?
>
> No. In fact, it does not yet exist at all. At EOSS2023 I presented a
> proposal, mostly to get an initial reaction, feedback, and see if there
> was interest from the RT community.
>
>> And what's the status of this effort?
>
> Right now I am dedicating my time towards finishing the printk work so
> that we can get PREEMPT_RT mainline. I plan on working on an rtapp
> tracer after that. If anyone else wants to start this work sooner, I am
> happy to contribute where I can.
Upstreaming is most important, absolutely.
/me neither has the time to start something at this point. But I see the
importance of this topic and would like to follow and, where possible,
contribute to such an effort. Just recently, I had to explain to
colleagues lengthily where traps are when porting applications over -rt.
Codifying some of those issues into a runtime checker would definitely
be more helpful - though also much harder.
>
> BTW, it is not yet clear if it should be a tracer or an RV monitor. In
> the presentation [2] (starting at 50:15) you can hear Daniel's argument
> for implementing this as an RV monitor instead.
>
> In case you were interested in the bpftrace script I used as a
> proof-of-concept, I have attached it to this email. For it to work I
> used a Debian/bookworm system (12.0). The kernel package was
> linux-image-6.1.0-9-rt-amd64 (6.1.27-1) and the bpftrace package was
> version 0.17.0-1. However, in order for bpftrace to support kprobe
> offsets, I needed to rebuild the bpftrace package with the extra
> Build-Depends "libbfd-dev". As mentioned in the presentation, with any
> other kernel binary, the proof-of-concept demo probably won't work.
>
> Also be aware this was just a proof-of-concept. A real rtapp tracer will
> need to catch many more cases (as I mentioned in the presentation).
Thanks,
Jan
>
> John Ogness
>
> [1] https://static.sched.com/hosted_files/eoss2023/27/Proposing%20a%20new%20tracer%20to%20monitor%20RT%20task%20behavior%20-%20John%20Ogness.pdf
>
> [2] https://www.youtube.com/watch?v=E5cTgiHJKc0
>
--
Siemens AG, Technology
Linux Expert Center
prev parent reply other threads:[~2023-09-16 11:20 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-10 17:03 rtapp tracer Jan Kiszka
2023-09-11 13:40 ` John Ogness
2023-09-16 11:19 ` Jan Kiszka [this message]
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=12974db8-bc19-4149-8d15-219537f03cfc@siemens.com \
--to=jan.kiszka@siemens.com \
--cc=john.ogness@linutronix.de \
--cc=linux-rt-users@vger.kernel.org \
/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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).