Messages in this thread |  | | Date | Tue, 05 May 2026 08:01:58 +0000 | | Subject | Re: [PATCH v2 sched_ext/for-7.1] sched_ext: Invalidate dispatch decisions on CPU affinity changes | | From | Kuba Piecuch <> |
| |
Hi Tejun,
On Mon May 4, 2026 at 9:24 PM UTC, Tejun Heo wrote: > On Mon, May 04, 2026 at 08:00:50AM +0000, Kuba Piecuch wrote: >> Random thought: If exposing qseq values to BPF directly is undesirable, then >> perhaps a less objectionable approach would be to expose them as opaque >> cookie/token values? Same semantics, but fewer SCX internals leaking to BPF. > > Yeah, cookie sounds fine to me and let's clearly note that this is for > schedulers that don't implement properly synchronized dequeue.
Could you elaborate a bit on what you mean by "properly synchronized" here?
To me, introducing cookies is primarily about adding flexibility around managing the "dispatch window" between the qseq being probed and the actual dispatch attempt in finish_dispatch(). For example, a CPU can get a cookie and pass it to another CPU to perform the dispatch, which is not possible with the current interface.
On another, slightly related note: I'm considering making scx_bpf_dsq_insert() and other dispatch-related kfuncs that manipulate only CPU-local state callable while holding BPF spinlocks. This is something that the comment above scx_bpf_dsq_insert() explicitly mentions:
This function doesn't have any locking restrictions and may be called under BPF locks (in the future when BPF introduces more flexible locking).
I'm not sure what "more flexible locking" means here, but this can be accomplished by simply adding the kfuncs to the list of kfuncs callable under spinlocks in the BPF verifier.
Are you aware of any previous work on this? Any pushback from BPF folks?
Thanks, Kuba
|  |