Re: Reporting a performance regression in sched/fair on Unixbench Shell Scripts with commit a53ce18cacb4

From: Vincent Guittot
Date: Fri Jun 09 2023 - 12:52:38 EST


Hi Saeed,

On Fri, 9 Jun 2023 at 00:48, Saeed Mirzamohammadi
<saeed.mirzamohammadi@xxxxxxxxxx> wrote:
>
> Hi all,
>
> I’m reporting a regression of up to 8% with Unixbench Shell Scripts benchmarks after the following commit:
>
> Commit Data:
> commit-id : a53ce18cacb477dd0513c607f187d16f0fa96f71
> subject : sched/fair: Sanitize vruntime of entity being migrated
> author : vincent.guittot@xxxxxxxxxx
> author date : 2023-03-17 16:08:10
>
>
> We have observed this on our v5.4 and v4.14 kernel and not yet tested 5.15 but I expect the same.

It would be good to confirm that the regression is present on v6.3
where the patch has been merged originally. It can be that there is
hidden dependency with other patches introduced since v5.4

>
> ub_gcc_1copy_Shell_Scripts_1_concurrent : -0.01%
> ub_gcc_1copy_Shell_Scripts_8_concurrent : -0.1%
> ub_gcc_1copy_Shell_Scripts_16_concurrent : -0.12%%
> ub_gcc_56copies_Shell_Scripts_1_concurrent : -2.29%%
> ub_gcc_56copies_Shell_Scripts_8_concurrent : -4.22%
> ub_gcc_56copies_Shell_Scripts_16_concurrent : -4.23%
> ub_gcc_224copies_Shell_Scripts_1_concurrent : -5.54%
> ub_gcc_224copies_Shell_Scripts_8_concurrent : -8%
> ub_gcc_224copies_Shell_Scripts_16_concurrent : -7.05%
> ub_gcc_448copies_Shell_Scripts_1_concurrent : -6.4%
> ub_gcc_448copies_Shell_Scripts_8_concurrent : -8.35%
> ub_gcc_448copies_Shell_Scripts_16_concurrent : -7.09%
>
> Link to unixbench:
> github.com/kdlucas/byte-unixbench

I tried to reproduce the problem with v6.3 on my system but I don't
see any difference with or without the patch

Do you have more details on your setup ? number of cpu and topology ?

>
> Info about benchmark:
> "The shells scripts test measures the number of times per minute a
> process can start and reap a set of one, two, four and eight concurrent
> copies of a shell scripts where the shell script applies a series of
> transformation to a data file”
>
> I have also evaluated performance before and after both of these two commits (one if fixing the other) but I still observe the same regression (C1 is still the source of regression).
> C1. a53ce18cacb4 sched/fair: Sanitize vruntime of entity being migrated
> C2. 829c1651e9c4 sched/fair: sanitize vruntime of entity being placed

C2 has introduced some regressions because of the case of newly
migrated tasks that were not correctly managed and C1 fixes this
problem. Then, both have an impact on system that runs for days with
low prio task

Thanks,
Vincent


>
> Thank you very much,
> Saeed
>