linux-kernel - Re: [LKP] [sched/fair] 070f5e860e: reaim.jobs_per

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>] [day] [month] [year] [list]
Message-ID: <CAKfTPtAv8X7TsYz7OrG8qYHCGx3XUvBKKBMHX1mKNy26ctytvQ@mail.gmail.com>
Date:   Fri, 12 Jun 2020 17:23:56 +0200
From:   Vincent Guittot <vincent.guittot@...aro.org>
To:     Hillf Danton <hdanton@...a.com>
Cc:     Xing Zhengjun <zhengjun.xing@...ux.intel.com>,
        kernel test robot <rong.a.chen@...el.com>,
        Ingo Molnar <mingo@...nel.org>,
        Mel Gorman <mgorman@...hsingularity.net>,
        Peter Zijlstra <a.p.zijlstra@...llo.nl>,
        Juri Lelli <juri.lelli@...hat.com>,
        Steven Rostedt <rostedt@...dmis.org>,
        Valentin Schneider <valentin.schneider@....com>,
        Phil Auld <pauld@...hat.com>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [LKP] [sched/fair] 070f5e860e: reaim.jobs_per_min -10.5% regression

On Fri, 12 Jun 2020 at 13:06, Hillf Danton <hdanton@...a.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;
>