Re: [PATCH v3 sched_ext/for-7.3 25/36] sched_ext: Add the SCX_CAP_ENQ_IMMED cap

Hello, Andrea.

On Wed, Jul 08, 2026 at 03:06:36PM +0200, Andrea Righi wrote:
...
> I bisected it and this was to be the offending commit.
> 
> IIUC, what's happening is that qmap grants the child CPUs 2–3, but race-sched
> stressor can pin its tasks to CPU 1. Since the child has no enqueue capability
> there, the tasks repeatedly land on the reject DSQ and eventually trigger the
> RCU stall.
> 
> Maybe we need a forced fallback when a task's affinity mask has no active CPU on
> which its scheduler holds SCX_CAP_BASE?
> 
> Checking this only during sched_setaffinity() won't work because capabilities
> can be revoked after the affinity change succeeds. What do you think?

Yeah, I should have mentioned in the head message but there are still a few
missing pieces for full support. Two big ones:

- cgroup migrations don't move the tasks across schedulers as they should.

- No fallback mechanism when a sub-sched doesn't have any CPUs for some of
  its tasks.

So, after this series, things mostly work as long as tasks don't move across
cgroup boundaries and tasks in sub-scheds aren't affined to the cpus tha the
sub-sched doesn't have access to. Will update the head message.

I haven't decided on the details yet but it's most likely going to be
reserving some time slice off from the root sched to run the tasks w/o cpu
access.

Thanks.

-- 
tejun