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@xxxxxxx/ 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
|