From: "Prundeanu, Cristian" <cpru@amazon.com>
To: K Prateek Nayak <kprateek.nayak@amd.com>,
Peter Zijlstra <peterz@infradead.org>
Cc: "Mohamed Abuelfotoh, Hazem" <abuehaze@amazon.com>,
"Saidi, Ali" <alisaidi@amazon.com>,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
"Blake, Geoff" <blakgeof@amazon.com>,
"Csoma, Csaba" <csabac@amazon.com>,
"Doebel, Bjoern" <doebel@amazon.de>,
Gautham Shenoy <gautham.shenoy@amd.com>,
Swapnil Sapkal <swapnil.sapkal@amd.com>,
Joseph Salisbury <joseph.salisbury@oracle.com>,
Dietmar Eggemann <dietmar.eggemann@arm.com>,
Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-tip-commits@vger.kernel.org"
<linux-tip-commits@vger.kernel.org>,
"x86@kernel.org" <x86@kernel.org>
Subject: Re: EEVDF regression still exists
Date: Thu, 1 May 2025 16:16:07 +0000 [thread overview]
Message-ID: <CFA24C6D-8BC4-490D-A166-03BDF3C3E16C@amazon.com> (raw)
In-Reply-To: <f241b773-fca8-4be2-8a84-5d3a6903d837@amd.com>
Hi Prateek,
On 2025-04-29, 22:33, "K Prateek Nayak" <kprateek.nayak@amd.com <mailto:kprateek.nayak@amd.com>> wrote:
>>>> Here are the latest results for the EEVDF impact on database workloads.
>>>> The regression introduced in kernel 6.6 still persists and doesn't look
>>>> like it is improving.
>>>
>>> Well, I was under the impression it had actually been solved :-(
>>>
>>> My understanding from the last round was that Prateek and co had it
>>> sorted -- with the caveat being that you had to stick SCHED_BATCH in at
>>> the right place in MySQL start scripts or somesuch.
>>
>> The statement in the previous thread [1] was that using SCHED_BATCH improves
>> performance over default. While that still holds true, it is also equally true
>> about using SCHED_BATCH on kernel 6.5.
>>
>> So, when we compare 6.5 with recent kernels, both using SCHED_BATCH, the
>> regression is still visible. (Previously, we only compared SCHED_BATCH with
>> 6.5 default, leading to the wrong conclusion that it's a fix).
>
> P.S. Are the numbers for v6.15-rc4 + SCHED_BATCH comparable to v6.5
> default?
SCHED_BATCH does improve the performance both on 6.5 and on 6.12+; in my
testing, 6.12-SCHED_BATCH does not quite reach the 6.5-default (without
SCHED_BATCH) performance. Best case (6.15-rc3-SCHED_BATCH) is -3.6%, and
worst case (6.15-rc4-SCHED_BATCH) is -7.0% when compared to 6.5.13-default.
(Please keep in mind that the target isn't to get SCHED_BATCH to the same
level as 6.5-default; it's to resolve the regression from 6.5-default to
6.6+ default, and from 6.5-SCHED_BATCH to 6.6+ SCHED_BATCH).
> One more curious question: Does changing the base slice to a larger
> value (say 6ms) in conjunction with setting SCHED_BATCH on v6.15-rc4
> affect the benchmark result in any way?
I reran 6.15-rc4, with both 3ms (default) and 6ms. The larger base slice
slightly improves performance, more for SCHED_BATCH than for default.
6ms compared to 3ms same kernel (not compared to 6.5):
Kernel | Throughput | Latency
---------------------+------------+---------
6.15-rc4 default | +1.1% | -1.3%
6.15-rc4 SCHED_BATCH | +2.9% | -2.7%
Full details, reports and data:
https://github.com/aws/repro-collection/blob/main/repros/repro-mysql-EEVDF-regression/results/20250430/README.md
(These perf files all have the same schedstat version, hopefully "perf
sched stats diff" worked better this time).
-Cristian
next prev parent reply other threads:[~2025-05-01 16:16 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-29 21:38 Cristian Prundeanu
2025-04-29 21:56 ` Peter Zijlstra
2025-04-29 22:06 ` Prundeanu, Cristian
2025-04-30 3:33 ` K Prateek Nayak
2025-05-01 16:16 ` Prundeanu, Cristian [this message]
2025-05-02 5:56 ` K Prateek Nayak
2025-05-02 6:33 ` K Prateek Nayak
2025-05-02 18:06 ` Prundeanu, Cristian
2025-05-02 8:48 ` Peter Zijlstra
2025-05-02 16:52 ` Prundeanu, Cristian
2025-05-14 21:26 ` Dietmar Eggemann
2025-04-30 10:02 ` Peter Zijlstra
2025-05-02 7:08 ` Sapkal, Swapnil
2025-05-02 17:25 ` Prundeanu, Cristian
2025-05-02 17:52 ` Linus Torvalds
2025-05-03 3:34 ` K Prateek Nayak
2025-05-21 13:30 ` Cristian Prundeanu
2025-05-20 18:14 Cristian Prundeanu
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=CFA24C6D-8BC4-490D-A166-03BDF3C3E16C@amazon.com \
--to=cpru@amazon.com \
--cc=abuehaze@amazon.com \
--cc=alisaidi@amazon.com \
--cc=benh@kernel.crashing.org \
--cc=blakgeof@amazon.com \
--cc=bp@alien8.de \
--cc=csabac@amazon.com \
--cc=dietmar.eggemann@arm.com \
--cc=doebel@amazon.de \
--cc=gautham.shenoy@amd.com \
--cc=joseph.salisbury@oracle.com \
--cc=kprateek.nayak@amd.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-tip-commits@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=swapnil.sapkal@amd.com \
--cc=x86@kernel.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®