Re: [LKP] [sched/fair] 070f5e860e: reaim.jobs_per_min -10.5% regression

Vincent Guittot
2020-06-12T15:24:16Z

On Fri, 12 Jun 2020 at 13:06, Hillf Danton <hdanton@sina.com> wrote:
>
>
> On Fri, 12 Jun 2020 14:36:49 +0800 Xing Zhengjun wrote:
> > Hi Vincent,
> >
> > We test the regression still existed in v5.7, do you have time to
> > look at it? Thanks.
> >
> >
> > =========================================================================================
> > 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
> >
> > 9f68395333ad7f5b 070f5e860ee2bf588c99ef7b4c2 v5.7
> > ---------------- --------------------------- ---------------------------
> > %stddev %change %stddev %change %stddev
> > \ | \ | \
> > 0.69 -10.3% 0.62 -9.1% 0.62 reaim.child_systime
> > 0.62 -1.0% 0.61 +0.5% 0.62 reaim.child_utime
> > 66870 -10.0% 60187 -7.6% 61787 reaim.jobs_per_min
> > 16717 -10.0% 15046 -7.6% 15446 reaim.jobs_per_min_child
> > 97.84 -1.1% 96.75 -0.4% 97.43 reaim.jti
> > 72000 -10.8% 64216 -8.3% 66000 reaim.max_jobs_per_min
> > 0.36 +10.6% 0.40 +7.8% 0.39 reaim.parent_time
> > 1.58 ą 2% +71.0% 2.70 ą 2% +26.9% 2.01 ą 2% reaim.std_dev_percent
> > 0.00 ą 5% +110.4% 0.01 ą 3% +48.8% 0.01 ą 7% reaim.std_dev_time
> > 50800 -2.4% 49600 -1.6% 50000 reaim.workload
> >
> >
> > On 3/19/2020 10:38 AM, kernel test robot wrote:
> > > Greeting,
> > >
> > > FYI, we noticed a -10.5% regression of reaim.jobs_per_min due to commit:
> > >
> > >
> > > commit: 070f5e860ee2bf588c99ef7b4c202451faa48236 ("sched/fair: Take into account runnable_avg to classify group")
> > > https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git master
> > >
> > > in testcase: reaim
> > > on test machine: 4 threads Intel(R) Core(TM) i3-3220 CPU @ 3.30GHz with 4G memory
> > > with following parameters:
> > >
> > > runtime: 300s
> > > nr_task: 100%
> > > test: five_sec
> > > cpufreq_governor: performance
> > > ucode: 0x21
> > >
> > > test-description: REAIM is an updated and improved version of AIM 7 benchmark.
> > > test-url: https://sourceforge.net/projects/re-aim-7/
>
> Hi Xing
>
> After 070f5e860ee2 let's treat runnable the same way as util on
> comparing capacity in the assumption that
> (125 + 110 + 117) / 3 = 117 accounts for 105 within margin of error
> before any other proposal with some more reasons.
>
> thanks
> Hillf
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -8215,12 +8215,8 @@ group_has_capacity(unsigned int imbalanc
> if (sgs->sum_nr_running < sgs->group_weight)
> return true;
>
> - if ((sgs->group_capacity * imbalance_pct) <
> - (sgs->group_runnable * 100))
> - return false;
> -
> - if ((sgs->group_capacity * 100) >
> - (sgs->group_util * imbalance_pct))
> + if ((sgs->group_capacity * 100) > (sgs->group_util * imbalance_pct) &&
> + (sgs->group_capacity * 100) > (sgs->group_runnable * imbalance_pct))

This change amplifies what the original patch is doing by reducing the
threshold that move cases from "has spare capacity" to "is overloaded"
state

> return true;
>
> return false;
> @@ -8240,12 +8236,8 @@ group_is_overloaded(unsigned int imbalan
> if (sgs->sum_nr_running <= sgs->group_weight)
> return false;
>
> - if ((sgs->group_capacity * 100) <
> - (sgs->group_util * imbalance_pct))
> - return true;
> -
> - if ((sgs->group_capacity * imbalance_pct) <
> - (sgs->group_runnable * 100))
> + if ((sgs->group_capacity * 100) < (sgs->group_util * imbalance_pct) ||
> + (sgs->group_capacity * 100) < (sgs->group_runnable * imbalance_pct))
> return true;
>
> return false;
>