From: K Prateek Nayak <kprateek.nayak@amd.com>
To: Cristian Prundeanu <cpru@amazon.com>
Cc: <abuehaze@amazon.com>, <alisaidi@amazon.com>,
<benh@kernel.crashing.org>, <blakgeof@amazon.com>,
<csabac@amazon.com>, <doebel@amazon.com>,
<gautham.shenoy@amd.com>, <joseph.salisbury@oracle.com>,
<dietmar.eggemann@arm.com>,
<linux-arm-kernel@lists.infradead.org>,
<linux-kernel@vger.kernel.org>,
<linux-tip-commits@vger.kernel.org>, <mingo@redhat.com>,
<peterz@infradead.org>, <x86@kernel.org>
Subject: Re: [PATCH 0/2] [tip: sched/core] sched: Disable PLACE_LAG and RUN_TO_PARITY and move them to sysctl
Date: Tue, 26 Nov 2024 09:28:49 +0530 [thread overview]
Message-ID: <41d0bc96-2e42-4fa1-85df-a6a93611240c@amd.com> (raw)
In-Reply-To: <20241125113535.88583-1-cpru@amazon.com>
Hello Cristian,
On 11/25/2024 5:05 PM, Cristian Prundeanu wrote:
> Here are more results with recent 6.12 code, and also using SCHED_BATCH.
> The control tests were run anew on Ubuntu 22.04 with the current pre-built
> kernels 6.5 (baseline) and 6.8 (regression out of the box).
>
> When updating mysql from 8.0.30 to 8.4.2, the regression grew even larger.
> Disabling PLACE_LAG and RUN _TO_PARITY improved the results more than
> using SCHED_BATCH.
>
> Kernel | default | NO_PLACE_LAG and | SCHED_BATCH | mysql
> | config | NO_RUN_TO_PARITY | | version
> ---------+----------+------------------+-------------+---------
> 6.8 | -15.3% | | | 8.0.30
> 6.12-rc7 | -11.4% | -9.2% | -11.6% | 8.0.30
> | | | |
> 6.8 | -18.1% | | | 8.4.2
> 6.12-rc7 | -14.0% | -10.2% | -12.7% | 8.4.2
> ---------+----------+------------------+-------------+---------
>
> Confidence intervals for all tests are smaller than +/- 0.5%.
>
> I expect to have the repro package ready by the end of the week. Thank you
> for your collective patience and efforts to confirm these results.
Thank you! In the meantime, there is a new enhancement to perf-tool
being proposed to use the data from /proc/schedstat to profile workloads
and spot any obvious changes in the scheduling behavior at
https://lore.kernel.org/lkml/20241122084452.1064968-1-swapnil.sapkal@amd.com/
It applies cleanly on tip:sched/core at tag "sched-core-2024-11-18"
Would it be possible to use the perf-tool built there to collect
the scheduling stats for MySQL benchmark runs on both v6.5 and v6.8 and
share the output of "perf sched stats diff" and the two perf.data files
recorded?
It would help narrow down the regression if this can be linked to a
system-wide behavior. Data from a run with NO_PLACE_LAG and
NO_RUN_TO_PARITY can also help look at metrics that are helping
improve the performance combared to vanilla v6.8 case. The proposed
perf-tools changes are arch agnostic and should work on any system
as long as it has /proc/schedstats with version 15 and above.
>
> [..snip..]
>
--
Thanks and Regards,
Prateek
next prev parent reply other threads:[~2024-11-26 4:00 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-17 5:19 [PATCH 0/2] [tip: sched/core] sched: Disable PLACE_LAG and RUN_TO_PARITY and move them to sysctl Cristian Prundeanu
2024-10-17 5:19 ` [PATCH 1/2] [tip: sched/core] sched: Disable PLACE_LAG and RUN_TO_PARITY Cristian Prundeanu
2024-10-17 5:20 ` [PATCH 2/2] [tip: sched/core] sched: Move PLACE_LAG and RUN_TO_PARITY to sysctl Cristian Prundeanu
2024-10-17 9:10 ` [PATCH 0/2] [tip: sched/core] sched: Disable PLACE_LAG and RUN_TO_PARITY and move them " Peter Zijlstra
2024-10-17 18:19 ` Prundeanu, Cristian
2024-10-18 7:07 ` K Prateek Nayak
2024-10-18 9:54 ` Mohamed Abuelfotoh, Hazem
2024-11-14 20:10 ` Joseph Salisbury
2024-11-19 10:29 ` Dietmar Eggemann
2024-11-25 11:35 ` Cristian Prundeanu
2024-11-26 3:58 ` K Prateek Nayak [this message]
2024-11-26 15:12 ` Dietmar Eggemann
2024-11-28 10:32 ` Cristian Prundeanu
2024-11-29 10:12 ` Dietmar Eggemann
[not found] <C0E39DE3-EEEB-4A08-850F-A4B7EC809E3A@amazon.com>
2024-10-24 8:12 ` Benjamin Herrenschmidt
2024-10-25 14:43 ` Gautham R. Shenoy
2024-10-29 4:57 ` Cristian Prundeanu
2024-10-30 10:21 ` Dietmar Eggemann
2024-11-01 13:05 ` Peter Zijlstra
2024-11-04 10:19 ` Gautham R. Shenoy
2024-11-04 10:34 ` K Prateek Nayak
-- strict thread matches above, loose matches on Subject: below --
2025-01-28 23:09 Cristian Prundeanu
2025-02-11 3:27 ` K Prateek Nayak
2025-02-12 5:41 ` Cristian Prundeanu
2025-02-12 9:43 ` Peter Zijlstra
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=41d0bc96-2e42-4fa1-85df-a6a93611240c@amd.com \
--to=kprateek.nayak@amd.com \
--cc=abuehaze@amazon.com \
--cc=alisaidi@amazon.com \
--cc=benh@kernel.crashing.org \
--cc=blakgeof@amazon.com \
--cc=cpru@amazon.com \
--cc=csabac@amazon.com \
--cc=dietmar.eggemann@arm.com \
--cc=doebel@amazon.com \
--cc=gautham.shenoy@amd.com \
--cc=joseph.salisbury@oracle.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=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;
as well as URLs for NNTP newsgroup(s).