[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <41d0bc96-2e42-4fa1-85df-a6a93611240c@amd.com>
Date: Tue, 26 Nov 2024 09:28:49 +0530
From: K Prateek Nayak <kprateek.nayak@....com>
To: Cristian Prundeanu <cpru@...zon.com>
CC: <abuehaze@...zon.com>, <alisaidi@...zon.com>, <benh@...nel.crashing.org>,
<blakgeof@...zon.com>, <csabac@...zon.com>, <doebel@...zon.com>,
<gautham.shenoy@....com>, <joseph.salisbury@...cle.com>,
<dietmar.eggemann@....com>, <linux-arm-kernel@...ts.infradead.org>,
<linux-kernel@...r.kernel.org>, <linux-tip-commits@...r.kernel.org>,
<mingo@...hat.com>, <peterz@...radead.org>, <x86@...nel.org>
Subject: Re: [PATCH 0/2] [tip: sched/core] sched: Disable PLACE_LAG and
RUN_TO_PARITY and move them to sysctl
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
Powered by blists - more mailing lists