From: Fernand Sieber <sieberf@amazon.com>
To: <peterz@infradead.org>
Cc: <abusse@amazon.de>, <dwmw@amazon.co.uk>, <gmazz@amazon.de>,
<jschoenh@amazon.de>, <kprateek.nayak@amd.com>,
<linux-kernel@vger.kernel.org>, <liuyuxua@amazon.com>,
<mingo@redhat.com>, <nh-open-source@amazon.com>,
<rkagan@amazon.de>, <sieberf@amazon.com>,
<vincent.guittot@linaro.org>, <vineethr@linux.ibm.com>
Subject: Re: [PATCH] sched/core: Push tasks on force idle
Date: Fri, 28 Nov 2025 16:36:51 +0200 [thread overview]
Message-ID: <20251128143651.391406-1-sieberf@amazon.com> (raw)
In-Reply-To: <20251128133822.GB4067720@noisy.programming.kicks-ass.net>
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
prev parent reply other threads:[~2025-11-28 14:37 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-28 13:19 [PATCH] sched/core: Push tasks on force idle Fernand Sieber
2025-11-28 13:38 ` Peter Zijlstra
2025-11-28 14:36 ` Fernand Sieber [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20251128143651.391406-1-sieberf@amazon.com \
--to=sieberf@amazon.com \
--cc=abusse@amazon.de \
--cc=dwmw@amazon.co.uk \
--cc=gmazz@amazon.de \
--cc=jschoenh@amazon.de \
--cc=kprateek.nayak@amd.com \
--cc=linux-kernel@vger.kernel.org \
--cc=liuyuxua@amazon.com \
--cc=mingo@redhat.com \
--cc=nh-open-source@amazon.com \
--cc=peterz@infradead.org \
--cc=rkagan@amazon.de \
--cc=vincent.guittot@linaro.org \
--cc=vineethr@linux.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox