mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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


  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®