Re: [PATCH v2 sched_ext/for-7.1] sched_ext: Invalidate dispatch decisions on CPU affinity changes

[Kuba Piecuch <jpiecuch@google.com>]

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