From: Shubhang Kaushik <shubhang@os.amperecomputing.com>
To: Peter Zijlstra <peterz@infradead.org>, mingo@kernel.org
Cc: longman@redhat.com, chenridong@huaweicloud.com,
juri.lelli@redhat.com, vincent.guittot@linaro.org,
dietmar.eggemann@arm.com, rostedt@goodmis.org,
bsegall@google.com, mgorman@suse.de, vschneid@redhat.com,
tj@kernel.org, hannes@cmpxchg.org, mkoutny@suse.com,
cgroups@vger.kernel.org, linux-kernel@vger.kernel.org,
jstultz@google.com, kprateek.nayak@amd.com, qyousef@layalina.io
Subject: Re: [PATCH v3 0/7] sched: Flatten the pick
Date: Thu, 11 Jun 2026 19:29:41 -0700 (PDT) [thread overview]
Message-ID: <6f015e47-e4b6-8fd8-ed36-bac07c2bf372@os.amperecomputing.com> (raw)
In-Reply-To: <20260605105513.354837583@infradead.org>
Hello Peter,
I applied the `sched/flat` patchset from your tree on top of the
`tip/sched/core` base commit (9ebe5c3c29f62)/(7.1-rc2)
The evaluation was performed on an 80-core, Ampere Altra
system running Fedora Linux 41.
Benchmark Runs:-
1. Hackbench (Execution time in seconds: lower is better)
The data reveals a clear architectural pivot point at 4 tasks:
- Low Concurrency (< 4 tasks): Regresses by +1.8% to +4.0%.
Removing cgroup isolation boundaries expands the idle CPU search
adding slight overhead to the wake-up path.
* 1 Thread: (+1.8%)
* 2 Threads: (+4.0%)
* 2 Procs: (+3.3%)
- Tipping Point (4 tasks): Performance is completely flat.
* 4 Threads: (+0.03%)
* 4 Procs: (+0.1%)
- High Concurrency (>= 8 tasks): Improves by -0.7% to -2.3%.
Collapsing the tree structure down to a flat layout removes
multi-layer load tracking updates (update_load_avg), saving cycles
under load.
* 8 Threads: (-0.7%)
* 16 Threads: (-1.8%)
* 8 Procs: (-1.2%)
* 16 Procs: (-2.3%)
* 32 Procs: (-1.6%)
2. Schbench (Wakeup Tail Latency)
- 16 Threads (128kb footprint): 99.9th percentile tail latency drops
significantly by -12.21% (us). Operating on a unified runqueue layer
prevents induced group-level throttling.
- 32 Threads (128kb footprint): 99.9th percentile tail latency
regresses by +5.50% (us). Eliminating nested queues increases lock
contention during heavy simultaneous wakeups.
3. Sysbench
- Sysbench RAM: Throughput increases by +1.55% (MiB/sec). Fewer tree
traversals reduce cache-line bouncing, freeing up cycles.
The patchset trades minor low-load performance for better scaling and
tighter tail latencies under distributed load. However, the majority of
these deltas remain small and sit near the measurement noise floor (<=
4%).
Regards,
Shubhang Kaushik
On Fri, 5 Jun 2026, Peter Zijlstra wrote:
>
> Hi!
>
> New version, same story [1]. TL;DR:
>
> - Adds new cgroup_mode knob and implements new policies to address the
> hierarchy level weight mismatch.
>
> - Builds upon that base to create a flat / single runqueue scheduler where the
> cgroup hierarchy is expressed through dynamic weight management.
>
> I'm hoping to be able to merge these patches early in the next cycle (after
> 7.2-rc1).
>
> Random benchmark:
>
> Game vs 'for ((i=0; i<8; i++)) do nice ./spin.sh; done':
>
> Lutris / GE-Proton10-34 / Steam Runtime 3 (sniper)
> Intel Core i7-2600K
> AMD Radeon RX 580
>
> Shadows Awakening (GOG)
>
> default slice(*)
>
> FPS min 4.0 29.0
> avg 47.5 59.2
> max 83.7 83.7
>
> FT min 9.3 10.2
> avg 34.0 17.0
> max 121.2 30.0
>
> FPS (Frames Per Second)
> FT (FrameTime)
>
> [*] Command prefix: 'chrt -o --sched-runtime 100000 0'
>
>
> Changes since v2:
>
> - merged debug and prep patches
> - fixed update_entity_lag() on dequeue (Vincent)
> - fixed throttle vs tick (Prateek)
> - fixed wakeup_preempt_fair()
> - rebased on tip/sched/core
> - rewritten cgroup_mode changelogs
> - reworked cgroup_mode concur
> - added cgroup_mode tasks
> - changed default cgroup_mode
>
>
> [1] - https://lore.kernel.org/r/20260511113104.563854162@infradead.org
>
> Can also be had:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/peterz/queue.git sched/flat
>
> include/linux/cpuset.h | 6
> include/linux/sched.h | 1
> kernel/cgroup/cpuset.c | 15
> kernel/sched/core.c | 5
> kernel/sched/debug.c | 89 ++++
> kernel/sched/fair.c | 943 ++++++++++++++++++++++++-------------------------
> kernel/sched/pelt.c | 6
> kernel/sched/sched.h | 30 -
> 8 files changed, 607 insertions(+), 488 deletions(-)
>
>
next prev parent reply other threads:[~2026-06-12 2:29 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-05 12:40 [PATCH v3 0/7] sched: Flatten the pick Peter Zijlstra
2026-06-05 12:40 ` [PATCH v3 1/7] sched/fair: Add cgroup_mode switch Peter Zijlstra
2026-06-30 9:03 ` [tip: sched/core] " tip-bot2 for Peter Zijlstra
2026-06-05 12:40 ` [PATCH v3 2/7] sched/fair: Add cgroup_mode: up Peter Zijlstra
2026-06-05 15:07 ` Peter Zijlstra
2026-06-30 9:03 ` [tip: sched/core] " tip-bot2 for Peter Zijlstra
2026-06-05 12:40 ` [PATCH v3 3/7] sched/fair: Add cgroup_mode: max Peter Zijlstra
2026-06-10 15:09 ` Waiman Long
2026-06-10 15:42 ` Waiman Long
2026-06-11 13:49 ` Peter Zijlstra
2026-06-11 13:47 ` Peter Zijlstra
2026-06-11 20:57 ` Waiman Long
2026-06-30 9:03 ` [tip: sched/core] " tip-bot2 for Peter Zijlstra
2026-06-05 12:40 ` [PATCH v3 4/7] sched/fair: Add cgroup_mode: concur Peter Zijlstra
2026-06-30 9:03 ` [tip: sched/core] " tip-bot2 for Peter Zijlstra
2026-06-05 12:40 ` [PATCH v3 5/7] sched/fair: Add cgroup_mode: tasks Peter Zijlstra
2026-06-30 9:03 ` [tip: sched/core] " tip-bot2 for Peter Zijlstra
2026-06-05 12:40 ` [PATCH v3 6/7] sched/fair: Change the default cgroup_mode to concur Peter Zijlstra
2026-06-30 9:03 ` [tip: sched/core] " tip-bot2 for Peter Zijlstra
2026-06-05 12:40 ` [PATCH v3 7/7] sched/eevdf: Move to a single runqueue Peter Zijlstra
2026-06-20 3:54 ` Chen, Yu C
2026-06-26 11:40 ` Peter Zijlstra
2026-06-29 14:02 ` Vincent Guittot
2026-06-30 9:03 ` [tip: sched/core] sched/fair: Fix overflow in update_tg_cfs_runnable() tip-bot2 for Chen, Yu C
2026-06-30 9:03 ` [tip: sched/core] sched/eevdf: Move to a single runqueue tip-bot2 for Peter Zijlstra (Intel)
2026-06-09 5:37 ` [PATCH v3 0/7] sched: Flatten the pick K Prateek Nayak
2026-06-12 2:29 ` Shubhang Kaushik [this message]
2026-08-17 16:05 ` Szabina Korbai
2026-08-17 16:35 ` K Prateek Nayak
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=6f015e47-e4b6-8fd8-ed36-bac07c2bf372@os.amperecomputing.com \
--to=shubhang@os.amperecomputing.com \
--cc=bsegall@google.com \
--cc=cgroups@vger.kernel.org \
--cc=chenridong@huaweicloud.com \
--cc=dietmar.eggemann@arm.com \
--cc=hannes@cmpxchg.org \
--cc=jstultz@google.com \
--cc=juri.lelli@redhat.com \
--cc=kprateek.nayak@amd.com \
--cc=linux-kernel@vger.kernel.org \
--cc=longman@redhat.com \
--cc=mgorman@suse.de \
--cc=mingo@kernel.org \
--cc=mkoutny@suse.com \
--cc=peterz@infradead.org \
--cc=qyousef@layalina.io \
--cc=rostedt@goodmis.org \
--cc=tj@kernel.org \
--cc=vincent.guittot@linaro.org \
--cc=vschneid@redhat.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.