* [PATCH] sched_ext: Update scx_dispatch_dequeue() comments
@ 2026-09-23 21:34 Usama Arif
2026-09-23 23:20 ` Tejun Heo
0 siblings, 1 reply; 2+ messages in thread
From: Usama Arif @ 2026-09-23 21:34 UTC (permalink / raw)
To: arighi, bpf, bsegall, changwoo, dietmar.eggemann, etsal,
juri.lelli, kprateek.nayak, linux-kernel, mgorman, mingo, peterz,
rostedt, sched-ext, tj, vincent.guittot, void, vschneid,
yphbchou0911
Cc: Usama Arif
Remote consumption now reaches the !dsq branch with holding_cpu set,
just like direct dispatch. Also, the dsq-present branch races with
unlink_dsq_and_switch_rq_lock(), not dispatch_to_local_dsq().
Update both comments to describe the current transfer paths. No
functional change.
Suggested-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Usama Arif <usama.arif@linux.dev>
---
kernel/sched/ext/ext.c | 13 ++++++-------
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/kernel/sched/ext/ext.c b/kernel/sched/ext/ext.c
index 0135ff6824b03..f95d1cf8d3d1c 100644
--- a/kernel/sched/ext/ext.c
+++ b/kernel/sched/ext/ext.c
@@ -1832,10 +1832,9 @@ void scx_dispatch_dequeue(struct rq *rq, struct task_struct *p)
list_del_init(&p->scx.dsq_list.node);
/*
- * When dispatching directly from the BPF scheduler to a local
- * DSQ, the task isn't associated with any DSQ but
- * @p->scx.holding_cpu may be set under the protection of
- * %SCX_OPSS_DISPATCHING.
+ * When moving a task to a local DSQ through either direct dispatch
+ * or remote consumption, the task isn't associated with any DSQ but
+ * @p->scx.holding_cpu may be set.
*/
if (p->scx.holding_cpu >= 0)
p->scx.holding_cpu = -1;
@@ -1855,9 +1854,9 @@ void scx_dispatch_dequeue(struct rq *rq, struct task_struct *p)
scx_task_unlink_from_dsq(p, dsq);
} else {
/*
- * We're racing against dispatch_to_local_dsq() which already
- * removed @p from @dsq and set @p->scx.holding_cpu. Clear the
- * holding_cpu which tells dispatch_to_local_dsq() that it lost
+ * We're racing against unlink_dsq_and_switch_rq_lock(), which
+ * already removed @p from @dsq and set @p->scx.holding_cpu. Clear
+ * holding_cpu to tell unlink_dsq_and_switch_rq_lock() that it lost
* the race.
*/
WARN_ON_ONCE(!list_empty(&p->scx.dsq_list.node));
--
2.53.0-Meta
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: [PATCH] sched_ext: Update scx_dispatch_dequeue() comments
2026-09-23 21:34 [PATCH] sched_ext: Update scx_dispatch_dequeue() comments Usama Arif
@ 2026-09-23 23:20 ` Tejun Heo
0 siblings, 0 replies; 2+ messages in thread
From: Tejun Heo @ 2026-09-23 23:20 UTC (permalink / raw)
To: Usama Arif
Cc: arighi, bpf, bsegall, changwoo, dietmar.eggemann, etsal,
juri.lelli, kprateek.nayak, linux-kernel, mgorman, mingo, peterz,
rostedt, sched-ext, vincent.guittot, void, vschneid,
yphbchou0911, emil, david.dai
Hello, Usama.
On Wed, Sep 23, 2026 at 02:34:18PM -0700, Usama Arif wrote:
> /*
> - * When dispatching directly from the BPF scheduler to a local
> - * DSQ, the task isn't associated with any DSQ but
> - * @p->scx.holding_cpu may be set under the protection of
> - * %SCX_OPSS_DISPATCHING.
> + * When moving a task to a local DSQ through either direct dispatch
> + * or remote consumption, the task isn't associated with any DSQ but
> + * @p->scx.holding_cpu may be set.
> */
dispatch_to_local_dsq() sets holding_cpu for ops.dispatch() inserts too,
not just direct dispatches. Can you name dispatch_to_local_dsq() instead,
here and in the description?
Clearing holding_cpu here is also how dispatch_to_local_dsq() learns that
it lost to a dequeue. The old comment on the other branch described that,
but for the wrong branch. Can you add a sentence about it here?
Can you also rewrap both comments at 80 columns? A few lines go past it.
Thanks.
--
tejun
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2026-09-23 23:20 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2026-09-23 21:34 [PATCH] sched_ext: Update scx_dispatch_dequeue() comments Usama Arif
2026-09-23 23:20 ` Tejun Heo
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®