linux-kernel - Re: [tip:sched/eevdf] [sched/fair] e0c2ff903c: phoronix-test-suite.blogbench.Write.final

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 18 Aug 2023 09:54:54 +0800
From:   Chen Yu <yu.c.chen@...el.com>
To:     Peter Zijlstra <peterz@...radead.org>
CC:     kernel test robot <oliver.sang@...el.com>,
        <oe-lkp@...ts.linux.dev>, <lkp@...el.com>,
        <linux-kernel@...r.kernel.org>, <x86@...nel.org>,
        "Ingo Molnar" <mingo@...nel.org>,
        Mike Galbraith <umgwanakikbuti@...il.com>
Subject: Re: [tip:sched/eevdf] [sched/fair]  e0c2ff903c:
 phoronix-test-suite.blogbench.Write.final_score -34.8% regression

On 2023-08-14 at 14:49:14 +0200, Peter Zijlstra wrote:
> On Fri, Aug 11, 2023 at 09:11:21AM +0800, Chen Yu wrote:
> > On 2023-08-10 at 21:24:37 +0800, kernel test robot wrote:
> > > 
> > > 
> > > Hello,
> > > 
> > > kernel test robot noticed a -34.8% regression of phoronix-test-suite.blogbench.Write.final_score on:
> > > 
> > > 
> > > commit: e0c2ff903c320d3fd3c2c604dc401b3b7c0a1d13 ("sched/fair: Remove sched_feat(START_DEBIT)")
> > > https://git.kernel.org/cgit/linux/kernel/git/tip/tip.git sched/eevdf
> > > 
> > > testcase: phoronix-test-suite
> > > test machine: 96 threads 2 sockets Intel(R) Xeon(R) Gold 6252 CPU @ 2.10GHz (Cascade Lake) with 512G memory
> > > parameters:
> > > 
> > > 	test: blogbench-1.1.0
> > > 	option_a: Write
> > > 	cpufreq_governor: performance
> > > 
> 
> Is this benchmark fork() heavy?
>

It is not fork() heavy. After created the threads, it becomes a
loop to write to some files.
 
> > It seems that commit e0c2ff903c32 removed the sched_feat(START_DEBIT) for initial
> > task, but also increases the vruntime for non-initial task:
> > Before the e0c2ff903c32, the vruntime for a enqueued task is:
> > cfs_rq->min_vruntime
> > After the e0c2ff903c32, the vruntime for a enqueued task is:
> > avg_vruntime(cfs_rq) = \Sum v_i * w_i / W
> >                      = \Sum v_i / nr_tasks
> > which is usually higher than cfs_rq->min_vruntime, and we give less sleep bonus to
> > the wakee, which could bring more or less impact to different workloads.
> > But since later we switched to lag based placement, this new vruntime will minus
> > lag, which could mitigate this problem. 
> 
> Right.. but given this problem was bisected through the lag based
> placement to this commit, I wondered about fork() / pthread_create().
> 
> If this is indeed fork()/pthread_create() heavy, could you please see if
> disabling PLACE_DEADLINE_INITIAL helps?

Tested with PLACE_DEADLINE_INITIAL disabled, no much difference is observed.

The baseline is Commit 246c6d7ab4d0 ("sched/eevdf: Better handle mixed slice length")

PLACE_DEADLINE_I   NO_PLACE_DEADLINE_INITIAL
---------------- ---------------------------
       fail:runs  %reproduction    fail:runs
           |             |             |
      4166            -4.7%       3969        phoronix-test-suite.blogbench.Write.final_score
    330.88            +4.4%     345.49        phoronix-test-suite.time.elapsed_time
    330.88            +4.4%     345.49        phoronix-test-suite.time.elapsed_time.max
    150672            -0.0%     150640        phoronix-test-suite.time.file_system_inputs
  29947344            -2.2%   29277840        phoronix-test-suite.time.file_system_outputs
   1954038            -0.3%    1947949        phoronix-test-suite.time.involuntary_context_switches
    163.00            +1.2%     165.00        phoronix-test-suite.time.major_page_faults
     32256            +0.7%      32472        phoronix-test-suite.time.maximum_resident_set_size
    152607            -1.1%     150874        phoronix-test-suite.time.minor_page_faults
      4096            +0.0%       4096        phoronix-test-suite.time.page_size
      8169            -5.0%       7764        phoronix-test-suite.time.percent_of_cpu_this_job_got
     26616            -0.9%      26374        phoronix-test-suite.time.system_time
    416.59            +8.3%     450.98        phoronix-test-suite.time.user_time
   1764497            -0.8%    1749992        phoronix-test-suite.time.voluntary_context_switches


blogbench.Write.final_score on different commits in eevdf branch:

sched/fair: Add cfs_rq::avg_vruntime
5217

sched/fair: Remove sched_feat(START_DEBIT)
3223

sched/fair: Add lag based placement
2736

sched/fair: Implement an EEVDF-like scheduling policy
3942

sched/fair: Commit to EEVDF
3957

sched/eevdf: Better handle mixed slice length
3836


It seems that, "Remove sched_feat(START_DEBIT)" brings some impact
and "Implement an EEVDF-like scheduling policy" restores some
throughput. The score from "sched/fair: Add lag based placement"
might not be reliable that, in place_entity() it scales the vlag
based on se->load.weight directly, while
"Implement an EEVDF-like scheduling policy" fixes that by using
scale_load_down().

I'll check what RUN_TO_PARITY brings to blogbench.

thanks,
Chenyu