public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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


      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