diff options
| author | Tejun Heo <tj@kernel.org> | 2026-08-03 11:01:14 -1000 |
|---|---|---|
| committer | Tejun Heo <tj@kernel.org> | 2026-08-03 11:01:14 -1000 |
| commit | 13f1eae3b66257625f865babd4fb7c251c8c981e (patch) | |
| tree | 275f0bf881b9711f565e186d80d59fde959fc59c /tools/perf/scripts/python/stackcollapse.py | |
| parent | 78f8d726e62e0b72a4b11e5778d2d7e252b076c0 (diff) | |
sched_ext: Synchronize slice and dsq_vtime writes
p->scx.slice and p->scx.dsq_vtime writes have no synchronization rules. The
dsq insert kfuncs write both fields synchronously from whatever context
they're called in - a direct dispatch from ops.select_cpu() writes with only
pi_lock held - and, as the kfuncs are safe to call spuriously with the
invalid dispatch discarded later, a scheduler can modify any task's slice by
spuriously calling them. The latter stands in the way of an upcoming patch
which adds kernel-granted slices that the schedulers must not be able to
modify.
Give both fields explicit rules. While the task is running, sleeping or
queued on an rq-owned DSQ, the rq lock protects them - these are the states
where the kernel consumes the slice. While queued on a user DSQ or on the
BPF side, the kernel neither consumes nor decides on the fields and every
writer acts for the BPF scheduler - synchronizing the writers is the
scheduler's responsibility and whichever write lands last wins.
To conform, an insert kfunc no longer writes the fields when called. The
values travel with the dispatch and take effect when the task is inserted. A
discarded dispatch has no side effects. The rq lock rule is asserted at the
slice store.
Signed-off-by: Tejun Heo <tj@kernel.org>
Reviewed-by: Andrea Righi <arighi@nvidia.com>
Diffstat (limited to 'tools/perf/scripts/python/stackcollapse.py')
0 files changed, 0 insertions, 0 deletions
