Messages in this thread | | | From | Vincent Guittot <> | Date | Fri, 12 Jun 2020 17:23:56 +0200 | Subject | Re: [LKP] [sched/fair] 070f5e860e: reaim.jobs_per_min -10.5% regression |
| |
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; >
| |