Re: [PATCH 1/2] sched_ext: Add scx_tickbug, a scheduler that holds a task on an idle CPU

[Radu Toader <radu.m.toader@gmail.com>]

On Fri, Nov 06, 2026 at 06:59:50AM -1000, Tejun Heo wrote:
> Thanks for catching the bug. However, this scheduler is more of an one-off
> debug code and I'm not sure we want to carry this in tree. Maybe put it in a
> github gist or sth and point to it from the fix patch?

Fair enough. v2 is the one-line fix on its own.

Rather than a gist, the fix points at the v1 posting of this patch in
the archive, so the link cannot rot and needs no account:

  https://lore.kernel.org/lkml/20261106094343.174905-2-radu.m.toader@gmail.com/

One offer before I drop it entirely. tools/testing/selftests/sched_ext
already carries nohz_tick, which asserts that a finite-slice EXT task
restarts the scheduler tick after an idle interval on a NOHZ_FULL CPU.
The condition this scheduler holds could be asserted there as a selftest
instead of carried as an example scheduler in tools/sched_ext. If a
regression guard for this is worth having I will post it separately; if
not, the archive link is enough and I will leave it alone.

Either way, the reproducer turned out to have a bug of its own, which
the CI review found on the same posting: an untagged task pinned to the
target CPU starved in the shared DSQ, because the target CPU stops
consuming that DSQ while it is holding something and no other CPU may
take a task pinned there. With two tagged tasks handing off it could sit
until the watchdog unloaded the scheduler, which contradicts the "the
machine stays usable" claim in the commit message. Dispatching anything
with nr_cpus_allowed == 1 to its local DSQ fixes it. Noting it here in
case someone takes the thing out of the archive.

Thanks for the quick look.

Disclosure: this reply was written by Claude Opus 5 (Claude Code) and
sent on my behalf, in the same session as the patch; the patch changelog
carries the same note.