Re: [PATCH] sched: Skip schedule() in sched_yield() when CPU has no other work

Re: [PATCH] sched: Skip schedule() in sched_yield() when CPU has no other work

[Peter Zijlstra]

On Mon, Feb 02, 2026 at 06:00:38AM -0800, Daniel Hodges wrote:
> When a task calls sched_yield() but is the only runnable task on its
> CPU with no pending wakeups, there's nothing to yield to. In this case,
> skip the schedule() overhead entirely and return immediately.
> 
> The yield_task() callback is still invoked to preserve per-class
> semantics (e.g., SCHED_DEADLINE's dl_yielded flag for bandwidth
> reclamation). The early exit only occurs after yield_task() completes
> and only if nr_running == 1 and ttwu_pending is false.
> 
> Testing performed in a 32-CPU VM using virtme-ng:
> 
> stress-ng --yield 8, unpinned workers, 10s each, 30 runs:
>      Baseline:  10.18M yields/sec
>      Optimized: 11.58M yields/sec
> 
> The optimization benefits lightly-loaded systems and CPU-pinned
> workloads where tasks are often alone on their CPUs. On loaded systems
> where CPUs have multiple runnable tasks, the check fails and we fall
> through to the normal schedule() path with no regression.

What is calling sched_yield() enough for this to matter? Calling
sched_yield() outside of FIFO/DL is basically UB.

Re: [PATCH] sched: Skip schedule() in sched_yield() when CPU has no other work

[Daniel Hodges]

On Mon, Feb 02, 2026 at 04:14:02PM +0100, Peter Zijlstra wrote:
> On Mon, Feb 02, 2026 at 06:00:38AM -0800, Daniel Hodges wrote:
> > When a task calls sched_yield() but is the only runnable task on its
> > CPU with no pending wakeups, there's nothing to yield to. In this case,
> > skip the schedule() overhead entirely and return immediately.
> > 
> > The yield_task() callback is still invoked to preserve per-class
> > semantics (e.g., SCHED_DEADLINE's dl_yielded flag for bandwidth
> > reclamation). The early exit only occurs after yield_task() completes
> > and only if nr_running == 1 and ttwu_pending is false.
> > 
> > Testing performed in a 32-CPU VM using virtme-ng:
> > 
> > stress-ng --yield 8, unpinned workers, 10s each, 30 runs:
> >      Baseline:  10.18M yields/sec
> >      Optimized: 11.58M yields/sec
> > 
> > The optimization benefits lightly-loaded systems and CPU-pinned
> > workloads where tasks are often alone on their CPUs. On loaded systems
> > where CPUs have multiple runnable tasks, the check fails and we fall
> > through to the normal schedule() path with no regression.
> 
> What is calling sched_yield() enough for this to matter? Calling
> sched_yield() outside of FIFO/DL is basically UB.

Very good question. I did some more digging through profiles and a lot
of it is in the NCCL library:
https://github.com/search?q=repo%3ANVIDIA%2Fnccl%20sched_yield&type=code

One issue with some of the GPU workloads is that they run on large
machines and aren't always fully utilized. Does it make sense to
optimize the training libraries instead?