From: Changwoo Min <multics69@gmail.com>
To: tj@kernel.org, void@manifault.com, mingo@redhat.com,
peterz@infradead.org
Cc: changwoo@igalia.com, kernel-dev@igalia.com, linux-kernel@vger.kernel.org
Subject: [PATCH v3 0/5] sched_ext: Support high-performance monotonically non-decreasing clock
Date: Tue, 3 Dec 2024 23:27:57 +0900 [thread overview]
Message-ID: <20241203142802.36305-1-changwoo@igalia.com> (raw)
Many BPF schedulers (such as scx_central, scx_lavd, scx_rusty, scx_bpfland,
and scx_flash) frequently call bpf_ktime_get_ns() for tracking tasks' runtime
properties. If supported, bpf_ktime_get_ns() eventually reads a hardware
timestamp counter (TSC). However, reading a hardware TSC is not
performant in some hardware platforms, degrading IPC.
This patchset addresses the performance problem of reading hardware TSC
by leveraging the rq clock in the scheduler core, introducing a
scx_bpf_clock_get_ns() function for BPF schedulers. Whenever the rq clock
is fresh and valid, scx_bpf_clock_get_ns() provides the rq clock, which is
already updated by the scheduler core (update_rq_clock), so it can reduce
reading the hardware TSC.
When the rq lock is released (rq_unpin_lock) or a long-running
operations are done by the BPF scheduler (ops.running, ops.update_idle),
the rq clock is invalidated, so a subsequent scx_bpf_clock_get_ns() call
gets the fresh sched_clock for the caller.
In addition, scx_bpf_clock_get_ns() guarantees the clock is
monotonically non-decreasing for the same CPU, so the clock cannot go
backward in the same CPU.
Using scx_bpf_clock_get_ns() reduces the number of reading hardware TSC
by 40-70% (65% for scx_lavd, 58% for scx_bpfland, and 43% for scx_rusty)
for the following benchmark.
perf bench -f simple sched messaging -t -g 20 -l 6000
The patchset begins by managing the status of rq clock in the scheduler
core, then implementing scx_bpf_clock_get_ns(), and finally applying it
to the BPF schedulers.
ChangeLog v2 -> v3:
- To avoid unnecessarily modifying cache lines, scx_rq_clock_update()
and scx_rq_clock_stale() update the clock and flags only when a
sched_ext scheduler is enabled.
ChangeLog v1 -> v2:
- Rename SCX_RQ_CLK_UPDATED to SCX_RQ_CLK_VALID to denote the validity
of an rq clock clearly.
- Rearrange the clock and flags fields in struct scx_rq to make sure
they are in the same cacheline to minimize the cache misses
- Add an additional explanation to the commit message in the 2/5 patch
describing when the rq clock will be reused with an example.
- Fix typos
- Rebase the code to the tip of Tejun's sched_ext repo
Changwoo Min (5):
sched_ext: Implement scx_rq_clock_update/stale()
sched_ext: Manage the validity of scx_rq_clock
sched_ext: Implement scx_bpf_clock_get_ns()
sched_ext: Add scx_bpf_clock_get_ns() for BPF scheduler
sched_ext: Replace bpf_ktime_get_ns() to scx_bpf_clock_get_ns()
kernel/sched/core.c | 6 +-
kernel/sched/ext.c | 74 ++++++++++++++++++++++++
kernel/sched/sched.h | 50 +++++++++++-----
tools/sched_ext/include/scx/common.bpf.h | 1 +
tools/sched_ext/include/scx/compat.bpf.h | 5 ++
tools/sched_ext/scx_central.bpf.c | 4 +-
tools/sched_ext/scx_flatcg.bpf.c | 2 +-
7 files changed, 123 insertions(+), 19 deletions(-)
--
2.47.1
next reply other threads:[~2024-12-03 14:28 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-03 14:27 Changwoo Min [this message]
2024-12-03 14:27 ` [PATCH v3 1/5] sched_ext: Implement scx_rq_clock_update/stale() Changwoo Min
2024-12-03 23:23 ` Tejun Heo
2024-12-04 1:28 ` Changwoo Min
2024-12-03 14:27 ` [PATCH v3 2/5] sched_ext: Manage the validity of scx_rq_clock Changwoo Min
2024-12-03 23:26 ` Tejun Heo
2024-12-04 1:42 ` Changwoo Min
2024-12-04 18:46 ` Tejun Heo
2024-12-06 1:50 ` Changwoo Min
2024-12-03 14:28 ` [PATCH v3 3/5] sched_ext: Implement scx_bpf_clock_get_ns() Changwoo Min
2024-12-03 23:37 ` Tejun Heo
2024-12-04 5:17 ` Changwoo Min
2024-12-03 14:28 ` [PATCH v3 4/5] sched_ext: Add scx_bpf_clock_get_ns() for BPF scheduler Changwoo Min
2024-12-03 14:28 ` [PATCH v3 5/5] sched_ext: Replace bpf_ktime_get_ns() to scx_bpf_clock_get_ns() Changwoo Min
2024-12-03 23:40 ` Tejun Heo
2024-12-04 5:41 ` Changwoo Min
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=20241203142802.36305-1-changwoo@igalia.com \
--to=multics69@gmail.com \
--cc=changwoo@igalia.com \
--cc=kernel-dev@igalia.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=tj@kernel.org \
--cc=void@manifault.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
all inboxes | Powered by JetHome®