From: Tobias Schaffner <tobias.schaffner@siemens.com>
To: Steven Rostedt <rostedt@goodmis.org>,
Gabriele Monaco <gmonaco@redhat.com>
Cc: Jonathan Corbet <corbet@lwn.net>,
Shuah Khan <skhan@linuxfoundation.org>,
Masami Hiramatsu <mhiramat@kernel.org>,
Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
Jan Kiszka <jan.kiszka@siemens.com>,
Philippe Gerum <rpm@xenomai.org>,
linux-trace-kernel@vger.kernel.org, linux-doc@vger.kernel.org,
linux-kselftest@vger.kernel.org, linux-kernel@vger.kernel.org,
Tobias Schaffner <tobias.schaffner@siemens.com>
Subject: [RFC 0/3] rv: per-edge dwell-time statistics for per-cpu monitors
Date: Thu, 27 Aug 2026 09:23:57 +0200 [thread overview]
Message-ID: <20260827072400.45734-1-tobias.schaffner@siemens.com> (raw)
Hi Steven, Gabriele,
I am using the RV system for a downstream project called EVL (aka Xenomai4).
It is a small co-kernel system, small enough that I can model the whole
co-kernel with RV instead of just a fragment of it.
The patches in this series add a per-monitor "stats" file that exposes how
often an edge has been visited and the dwell time in the prior state for
per-cpu monitors.
This allows me to not only check if the model is correct but also to see if
all paths are exercised by my stress tooling and to decompose the latency of
the co-kernel's wakeup path.
I think that some of the upstream monitors like e.g. the sts monitor could also
profit from this.
As an example, here is the sts monitor on a StarFive VisionFive2 running an rt
kernel (isolcpus=2-3), after enabling it and generating some scheduler load.
Only the edges the automaton actually takes are non-zero:
# cat monitors/sched/sts/stats
# cpu edge label count max_ns sum_ns
0 0 can_sched:irq_disable 367732 3998500 14773091250
0 4 can_sched:schedule_entry 40282 398750 45510750
0 7 cant_sched:irq_enable 367732 32500 532791750
0 8 cant_sched:irq_entry 26188 6250 38357250
0 13 disable_to_switch:irq_enable 4933 12500 12275000
0 14 disable_to_switch:irq_entry 31 2250 35250
0 15 disable_to_switch:sched_switch 35373 26750 111615750
0 18 enable_to_exit:irq_disable 373 3250 649750
0 19 enable_to_exit:irq_enable 373 20000 1676250
0 20 enable_to_exit:irq_entry 309 4750 420000
0 23 enable_to_exit:schedule_exit 40298 3000 37335000
0 25 in_irq:irq_enable 31 12250 140750
0 30 scheduling:irq_disable 40337 18000 45449500
0 37 switching:irq_enable 35373 9250 72471000
[ cpus 1-2 omitted ]
3 0 can_sched:irq_disable 567 3983750 300860250
3 4 can_sched:schedule_entry 150 1500 171000
3 7 cant_sched:irq_enable 567 21500 1777500
3 8 cant_sched:irq_entry 76 6500 164750
3 15 disable_to_switch:sched_switch 150 4250 413750
3 23 enable_to_exit:schedule_exit 150 1500 147750
3 30 scheduling:irq_disable 150 1500 166000
3 37 switching:irq_enable 150 3750 277000
The sts model splits the schedule->switch path into separate states, so the
per-edge dwell decomposes the scheduler's interrupts-off window: on cpu0 the
prep phase (disable_to_switch, irqs off until the switch) tops out at 26.8us
and the switch itself (switching:irq_enable) at 9.3us, over 35k switches. The
counts also line up with the model, e.g. every irq_disable in can_sched has a
matching irq_enable in cant_sched (367732 == 367732). The isolated cpus 2-3
take almost no switches (150 on cpu3, versus 35k on cpu0) and their worst case
is tighter still (~4us), so the same file also makes the effect of cpu
isolation visible per cpu.
The changes are gated by CONFIG_RV_EDGE_STAT and dormant until a monitor is
enabled, so existing setups are unaffected. When enabled, each accepted
transition adds one local_clock() and a few lock-free local64_t updates. With
the config off there is no code on the hot path at all.
I focused on per-cpu monitors as a first step. Per-task and per-object
monitors would have to aggregate entities that share a cpu, which is harder
to get right, so I left them out for now.
What is your opinion on this? Do you think this is worth getting upstreamed?
Thanks for taking a look,
Tobias
Tobias Schaffner (3):
rv: add per-edge dwell-time statistics primitive
rv: add per-monitor edge-stat facility and stats file
rv: collect per-edge dwell time for per-cpu DA/HA monitors
.../trace/rv/runtime-verification.rst | 24 ++++
MAINTAINERS | 1 +
include/linux/rv.h | 18 +++
include/linux/rv_edge_stat.h | 60 +++++++++
include/rv/da_monitor.h | 53 ++++++++
kernel/trace/rv/Kconfig | 11 ++
kernel/trace/rv/rv.c | 116 +++++++++++++++++-
tools/testing/selftests/verification/config | 1 +
.../verification/test.d/rv_edge_stats.tc | 32 +++++
9 files changed, 315 insertions(+), 1 deletion(-)
create mode 100644 include/linux/rv_edge_stat.h
create mode 100644 tools/testing/selftests/verification/test.d/rv_edge_stats.tc
--
2.43.0
next reply other threads:[~2026-08-27 7:24 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-27 7:23 Tobias Schaffner [this message]
2026-08-27 7:23 ` [RFC 1/3] rv: add per-edge dwell-time statistics primitive Tobias Schaffner
2026-08-27 7:34 ` sashiko-bot
2026-08-27 8:22 ` Gabriele Monaco
2026-08-27 10:10 ` Tobias Schaffner
2026-08-27 7:23 ` [RFC 2/3] rv: add per-monitor edge-stat facility and stats file Tobias Schaffner
2026-08-27 7:39 ` sashiko-bot
2026-08-27 7:24 ` [RFC 3/3] rv: collect per-edge dwell time for per-cpu DA/HA monitors Tobias Schaffner
2026-08-27 7:37 ` sashiko-bot
2026-08-27 8:18 ` [RFC 0/3] rv: per-edge dwell-time statistics for per-cpu monitors Gabriele Monaco
2026-08-27 18:21 ` Tobias Schaffner
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=20260827072400.45734-1-tobias.schaffner@siemens.com \
--to=tobias.schaffner@siemens.com \
--cc=corbet@lwn.net \
--cc=gmonaco@redhat.com \
--cc=jan.kiszka@siemens.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=linux-trace-kernel@vger.kernel.org \
--cc=mathieu.desnoyers@efficios.com \
--cc=mhiramat@kernel.org \
--cc=rostedt@goodmis.org \
--cc=rpm@xenomai.org \
--cc=skhan@linuxfoundation.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