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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20251128143651.391406-1-sieberf@amazon.com>
Date: Fri, 28 Nov 2025 16:36:51 +0200
From: Fernand Sieber <sieberf@...zon.com>
To: <peterz@...radead.org>
CC: <abusse@...zon.de>, <dwmw@...zon.co.uk>, <gmazz@...zon.de>,
	<jschoenh@...zon.de>, <kprateek.nayak@....com>,
	<linux-kernel@...r.kernel.org>, <liuyuxua@...zon.com>, <mingo@...hat.com>,
	<nh-open-source@...zon.com>, <rkagan@...zon.de>, <sieberf@...zon.com>,
	<vincent.guittot@...aro.org>, <vineethr@...ux.ibm.com>
Subject: Re: [PATCH] sched/core: Push tasks on force idle

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@amazon.com
> >
> > 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@amazon.com)
- 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@amazon.com
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@amazon.com/



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