ops.cpu_acquire/release() are deprecated in favor of tracking CPU
preemption from a sched_switch tracepoint, see
commit a3f5d48222 ("sched_ext: Allow scx_bpf_reenqueue_local() to
be called from anywhere"). Loading scx_pair currently emits a
deprecation warning.
Replace the pair_cpu_acquire/release() callbacks with a
tp_btf/sched_switch program that edge-detects the same transitions the
core used to deliver: a release when a running SCX task loses its CPU
to a higher-priority class, and an acquire when the CPU switches back
to an SCX task or idle while marked preempted.
Tasks are classified by effective priority (p->prio) rather than by
policy: rt_mutex_setprio() boosts a PI beneficiary into the rt/dl
classes while leaving its policy untouched, so a policy test would
both miss the release when a boosted task takes the CPU and fire a
spurious acquire when a boosted task replaces a real rt task.
A switch from idle straight to a higher-priority task is deliberately
not treated as a release. The CPU was not running an SCX task, so
there is nothing to drain, and kicking SCX_KICK_PREEMPT |
SCX_KICK_WAIT on every rt wakeup would make the pair CPU wait out rt
bursts it was never coupled to. The old callbacks behaved the same
way, firing ops.cpu_release() only from switch_class() when an SCX
task was put for a higher class.
The tracepoint runs on every context switch in the system, so the
common no-transition case is filtered before taking the pair-shared
lock. This is safe because a CPU's own preempted_mask bit is only ever
written by this tracepoint running on that CPU.
sched_setscheduler() on a running task changes class in place without
a context switch, so such transitions are only observed at the task's
next switch. The old callbacks had the same blind spot in
switch_class(), and try_dispatch() already bounds the resulting wait.
Verified in virtme-ng with the script below. The scheduler must load
without the deprecation warning, stay enabled through the rt churn and
the idle soak (the watchdog would otherwise abort it with "runnable
task stall"), keep its preemption counter advancing, and unregister
cleanly at the end. A PI rt-mutex churn that repeatedly boosts
SCX tasks into the rt class was exercised separately:
#!/bin/bash
# vng --verbose --cpus 8 -m 4G --user root -- ./verify.sh
# FIFO harness: survives even if all SCHED_NORMAL tasks stall
[ "${RT:-0}" = 1 ] || exec chrt -f 5 env RT=1 "$0"
chrt -o 0 ./tools/sched_ext/build/bin/scx_pair &
PAIR=$!
sleep 3
for round in $(seq 10); do
pids=""
for i in 0 1 2 3; do # SCHED_FIFO churn
chrt -f 10 bash -c \
'e=$((SECONDS+1)); while [ $SECONDS -lt $e ]; do :; done' &
pids="$pids $!"
done
for i in 0 1; do # SCHED_NORMAL load under scx
chrt -o 0 bash -c \
'n=0; while [ $n -lt 200000 ]; do n=$((n+1)); done' &
pids="$pids $!"
done
wait $pids # explicit pids, not the scx_pair job
done
sleep 300 # idle soak
kill -INT $PAIR # expect clean unregister in dmesg
Signed-off-by: Cheng-Yang Chou <yphbchou0911@gmail.com>
Reviewed-by: Andrea Righi <arighi@nvidia.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
2abee44c7d