From: Shubhang Kaushik <shubhang@os.amperecomputing.com>
To: Christian Loehle <christian.loehle@arm.com>,
linux-kernel@vger.kernel.org, peterz@infradead.org,
mingo@redhat.com, vincent.guittot@linaro.org
Cc: juri.lelli@redhat.com, dietmar.eggemann@arm.com,
kprateek.nayak@amd.com, pierre.gondois@arm.com
Subject: Re: [PATCHv2] sched/fair: Skip SCHED_IDLE rq for SCHED_IDLE task
Date: Wed, 4 Feb 2026 16:00:51 -0800 (PST) [thread overview]
Message-ID: <7313b320-779a-f5ad-418c-9c15f0cc6986@os.amperecomputing.com> (raw)
In-Reply-To: <20260203184939.2138022-1-christian.loehle@arm.com>
[-- Attachment #1: Type: text/plain, Size: 4177 bytes --]
On Tue, 3 Feb 2026, Christian Loehle wrote:
> CPUs whose rq only have SCHED_IDLE tasks running are considered to be
> equivalent to truly idle CPUs during wakeup path. For fork and exec
> SCHED_IDLE is even preferred.
> This is based on the assumption that the SCHED_IDLE CPU is not in an
> idle state and might be in a higher P-state, allowing the task/wakee
> to run immediately without sharing the rq.
>
> However this assumption doesn't hold if the wakee has SCHED_IDLE policy
> itself, as it will share the rq with existing SCHED_IDLE tasks. In this
> case, we are better off continuing to look for a truly idle CPU.
>
> On a Intel Xeon 2-socket with 64 logical cores in total this yields
> for kernel compilation using SCHED_IDLE:
>
> +---------+----------------------+----------------------+--------+
> | workers | mainline (seconds) | patch (seconds) | delta% |
> +=========+======================+======================+========+
> | 1 | 4384.728 ± 21.085 | 3843.250 ± 16.235 | -12.35 |
> | 2 | 2242.513 ± 2.099 | 1971.696 ± 2.842 | -12.08 |
> | 4 | 1199.324 ± 1.823 | 1033.744 ± 1.803 | -13.81 |
> | 8 | 649.083 ± 1.959 | 559.123 ± 4.301 | -13.86 |
> | 16 | 370.425 ± 0.915 | 325.906 ± 4.623 | -12.02 |
> | 32 | 234.651 ± 2.255 | 217.266 ± 0.253 | -7.41 |
> | 64 | 202.286 ± 1.452 | 197.977 ± 2.275 | -2.13 |
> | 128 | 217.092 ± 1.687 | 212.164 ± 1.138 | -2.27 |
> +---------+----------------------+----------------------+--------+
>
> Signed-off-by: Christian Loehle <christian.loehle@arm.com>
I’ve been testing this patch on an 80-core Ampere Altra (Neoverse-N1) and
the results look very solid. On these high-core-count ARM systems, we
definitely see the benefit of being pickier about where we place
SCHED_IDLE tasks.
Treating an occupied SCHED_IDLE rq as idle seems to cause
unnecessary packing that shows up in the tail latency. By spreading these
background tasks to truly idle cores, I'm seeing a nice boost in both
background compilation and AI inference throughput.
The reduction in sys time confirms that the domain balancing remains
stable despite the refactor to sched_idle_rq(rq) as you and Prateek
mentioned.
1. Background Kernel Compilation:
I ran `time nice -n 19 make -j$nproc` to see how it handles a heavy
background load. We saved nearly 3 minutes of 'sys' time showing
lower scheduler overhead.
Mainline (6.19.0-rc8):
real 9m28.403s
sys 219m21.591s
Patched:
real 9m16.167s (-12.2s)
sys 216m28.323s (-2m53s)
I was initially concerned about the impact on domain balancing, but the
significant reduction in 'sys' time during the kernel build confirms that
we aren't seeing any regressive balancing overhead.
2. AI Inference (llama-batched-bench):
For background LLM inference, the patch consistently delivered about 8.7%
more throughput when we're running near core saturation.
51 Threads: 30.03 t/s (vs 27.62 on Mainline) -> +8.7%
80 Threads: 27.20 t/s (vs 25.01 on Mainline) -> +8.7%
3. Scheduler Latency using schbench:
The biggest win was in the p99.9 tail latency. Under a locked workload,
the latency spikes dropped significantly.
4 Threads (Locking): 10085 us (vs 12421 us) -> -18.8%
8 Threads (Locking): 9563 us (vs 11589 us) -> -17.5%
The patch really helps clean up the noise for background tasks on these
large ARM platforms. Nice work.
Tested-by: Shubhang Kaushik <shubhang@os.amperecomputing.com>
Regards,
Shubhang Kaushik
> int cpu = rq->cpu;
> - int busy = idle != CPU_IDLE && !sched_idle_cpu(cpu);
ma> + int busy = idle != CPU_IDLE && !sched_idle_rq(rq);
> unsigned long interval;
> struct sched_domain *sd;
> /* Earliest time when we have to do rebalance again */
> @@ -12299,7 +12305,7 @@ static void sched_balance_domains(struct rq *rq, enum cpu_idle_type idle)
> * state even if we migrated tasks. Update it.
> */
> idle = idle_cpu(cpu);
> - busy = !idle && !sched_idle_cpu(cpu);
> + busy = !idle && !sched_idle_rq(rq);
> }
> sd->last_balance = jiffies;
> interval = get_sd_balance_interval(sd, busy);
> --
> 2.34.1
>
>
next prev parent reply other threads:[~2026-02-05 0:00 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-03 18:49 Christian Loehle
2026-02-04 2:08 ` Shubhang Kaushik
2026-02-04 7:54 ` K Prateek Nayak
2026-02-04 9:53 ` Christian Loehle
2026-02-04 7:48 ` K Prateek Nayak
2026-02-04 10:10 ` Christian Loehle
2026-02-04 10:53 ` Vincent Guittot
2026-02-05 0:00 ` Shubhang Kaushik [this message]
2026-02-05 7:25 ` Vincent Guittot
2026-02-05 18:52 ` Shubhang Kaushik
2026-02-06 13:43 ` Christian Loehle
2026-02-06 18:50 ` Shubhang Kaushik
2026-02-24 9:13 ` [tip: sched/core] " tip-bot2 for Christian Loehle
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=7313b320-779a-f5ad-418c-9c15f0cc6986@os.amperecomputing.com \
--to=shubhang@os.amperecomputing.com \
--cc=christian.loehle@arm.com \
--cc=dietmar.eggemann@arm.com \
--cc=juri.lelli@redhat.com \
--cc=kprateek.nayak@amd.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=pierre.gondois@arm.com \
--cc=vincent.guittot@linaro.org \
/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
all inboxes | Powered by JetHome®