Re: [PATCH] sched/core: Push tasks on force idle

[Fernand Sieber]

On Fri, Nov 28, 2025 at 02:38:22PM +0100, Peter Zijlstra wrote:
> On Fri, Nov 28, 2025 at 03:19:54PM +0200, Fernand Sieber wrote:
> > When a cpu enters force idle, it will
> > 1) try to steal cookie matching tasks from other CPUs
> > 2) do the newidle balance
> >
> > If the stealing fails, we are out of options to get out of force idle
> > properly. New idle balance might decide to pull other tasks, but they
> > won't necessarily be matching anyways.
> >
> > Introduce a step in between where we try to push the runnable tasks
> > that are blocked in force idle to a more suitable CPU.
> >
> > === Testing setup ===
> >
> > Similar setup as in:
> > https://lore.kernel.org/lkml/20251127202719.963766-1-sieberf@xxxxxxxxxx
> >
> > Testing is aimed at measuring perceived guest noise on hypervisor
> > system with time shared scenarios.
> >
> > Setup is on system where the load is nearing 100% which should allow no
> > steal time. The system has 64 CPUs, with 8 VMs, each VM using core
> > scheduling with 8 vCPUs per VM, time shared.
> >
> > 7 VMs are running stressors (`stress-ng --cpu 0`) while the last VM is
> > running the hwlat tracer with a width of 100ms, a period of 300ms, and
> > a threshold of 100us. Each VM runs a cookied non vCPU VMM process that
> > adds a light level of noise which forces some level of load balancing.
> >
> > The test scenario is ran 10x60s and the average noise is measured (we
> > use breaches scaled up to period/width to estimate noise).
> >
> > === Testing results ===
> >
> > Baseline noise: 1.20%
> > After patch noise: 0.66% (-45%)
>
> This is similar to that other patch, what happens if you combine the
> two?

Noise results:
- Baseline: 1.20%
- Force idle aware LB: 0.63%
  (https://lore.kernel.org/lkml/20251127202719.963766-1-sieberf@xxxxxxxxxx)
- Push force idle tasks: 0.66% (this patch)
- Both patches combined: 0.45%

Note: I realized I also ran these tests with this patch applied on
baseline:
"sched/fair: Add more core cookie check in wake up fast path"
https://lore.kernel.org/lkml/20251120101955.968586-1-sieberf@xxxxxxxxxx
Ideally I would revert it and compute all improvements independently.
Prateek already reviewed that patch, I would appreciate if you could
take a look too.

I could post all the patches together, though I thought they are fairly
independent so it's easier to keep them separate.

Additionally, to craft these patches I examined inefficiency
opportunities tracked with scheduling ftrace dumps, for which I also
relied on a cookie tracepoint proposed here:
https://lore.kernel.org/lkml/20250128113410.263994-1-sieberf@xxxxxxxxxx/



Amazon Development Centre (South Africa) (Proprietary) Limited
29 Gogosoa Street, Observatory, Cape Town, Western Cape, 7925, South Africa
Registration Number: 2004 / 034463 / 07