On Fri, 19 Jun 2020 at 09:15, Vincent Guittot <[email protected]> wrote: > > On Fri, 19 Jun 2020 at 06:55, Xing Zhengjun > <[email protected]> wrote: > > On 6/17/2020 10:57 PM, Vincent Guittot wrote: > > > Le mercredi 17 juin 2020 à 08:30:21 (+0800), Xing Zhengjun a écrit : > > ... > > > > OK. So the regression disappears when the conditions on runnable_avg are > > > removed. > > > > > > In the meantime, I have been able to understand more deeply what was > > > happeningi > > > for this bench and how it is impacted by > > > commit: 070f5e860ee2 ("sched/fair: Take into account runnable_avg to > > > classify group") > > > > > > This bench forks a new thread for each and every new step. But a newly > > > forked > > > threads start with a load_avg and a runnable_avg set to max whereas the > > > threads > > > are running shortly before exiting. This makes the CPU to be set > > > overloaded in > > > some case whereas it isn't. > > > > > > Could you try the patch below ? > > > It fixes the problem on my setup (I have finally been able to reproduce > > > the problem) > > > > > > --- > > > kernel/sched/fair.c | 2 +- > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c > > > index 0aeffff62807..b33a4a9e1491 100644 > > > --- a/kernel/sched/fair.c > > > +++ b/kernel/sched/fair.c > > > @@ -807,7 +807,7 @@ void post_init_entity_util_avg(struct task_struct *p) > > > } > > > } > > > > > > - sa->runnable_avg = cpu_scale; > > > + sa->runnable_avg = sa->util_avg; > > > > > > if (p->sched_class != &fair_sched_class) { > > > /* > > > > > > > I apply the patch above based on v5.7, the test result is as the following: > > Thanks for the tests. > > This patch fixes the regression on the test. I'm going to run more > tests to make sure that it doesn't regress others benchmarks. I > remember that some were slightly better with the original behavior but > others patches and fixes have been added in the meantime that might > change the results.
I have run more test on large and small system and the results are balanced. I might see a small regression on some hackbenchs results on large system but it's in the range of the stdev and might not be significant I'm going to send a clean patch with a commit message. Thanks for your help Vincent > > > > > ========================================================================================= > > tbox_group/testcase/rootfs/kconfig/compiler/runtime/nr_task/debug-setup/test/cpufreq_governor/ucode: > > > > lkp-ivb-d04/reaim/debian-x86_64-20191114.cgz/x86_64-rhel-7.6/gcc-7/300s/100%/test/five_sec/performance/0x21 > > > > commit: > > 9f68395333ad7f5bfe2f83473fed363d4229f11c > > 070f5e860ee2bf588c99ef7b4c202451faa48236 > > v5.7 > > cbb4d668e7431479a7978fa79d64c2271adefab0 ( the test patch which modify > > post_init_entity_util_avg()) > > > > 9f68395333ad7f5b 070f5e860ee2bf588c99ef7b4c2 v5.7 > > cbb4d668e7431479a7978fa79d6 > > ---------------- --------------------------- --------------------------- > > --------------------------- > > %stddev %change %stddev %change > > %stddev %change %stddev > > \ | \ | \ > > | \ > > 0.69 -10.3% 0.62 -9.1% 0.62 > > +0.6% 0.69 reaim.child_systime > > 0.62 -1.0% 0.61 +0.5% 0.62 > > -0.3% 0.62 reaim.child_utime > > 66870 -10.0% 60187 -7.6% 61787 > > +0.7% 67335 reaim.jobs_per_min > > > > > 16717 -10.0% 15046 -7.6% 15446 > > +0.7% 16833 reaim.jobs_per_min_child > > 97.84 -1.1% 96.75 -0.4% 97.43 > > +0.2% 98.05 reaim.jti > > 72000 -10.8% 64216 -8.3% 66000 > > +0.0% 72000 reaim.max_jobs_per_min > > 0.36 +10.6% 0.40 +7.8% 0.39 > > -0.6% 0.36 reaim.parent_time > > 1.58 ± 2% +71.0% 2.70 ± 2% +26.9% 2.01 ± > > 2% -8.8% 1.44 ± 2% reaim.std_dev_percent > > 0.00 ± 5% +110.4% 0.01 ± 3% +48.8% 0.01 ± > > 7% -24.6% 0.00 ± 7% reaim.std_dev_time > > 50800 -2.4% 49600 -1.6% 50000 > > +0.0% 50800 reaim.workload > > > > > > -- > > Zhengjun Xing
