linux-kernel - Re: [sched/fair] 0b0695f2b3: phoronix-test-suite.compress-gzip.0.seconds 19.8% regression

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] [day] [month] [year] [list]

Message-ID: <CAKfTPtApE09vGpEt=jTJk2yY9Lmy5tjNsRUNdqpRJV0_SvgZvg@mail.gmail.com>
Date:   Fri, 5 Jun 2020 09:06:11 +0200
From:   Vincent Guittot <vincent.guittot@...aro.org>
To:     Mel Gorman <mgorman@...e.de>
Cc:     Oliver Sang <oliver.sang@...el.com>,
        Ingo Molnar <mingo@...nel.org>,
        Ben Segall <bsegall@...gle.com>,
        Dietmar Eggemann <dietmar.eggemann@....com>,
        Juri Lelli <juri.lelli@...hat.com>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Mike Galbraith <efault@....de>,
        Peter Zijlstra <peterz@...radead.org>,
        Steven Rostedt <rostedt@...dmis.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        LKML <linux-kernel@...r.kernel.org>, lkp@...ts.01.org,
        OTC LSE PnP <otc.lse.pnp@...el.com>,
        "Huang, Ying" <ying.huang@...el.com>,
        "Si, Beibei" <beibei.si@...el.com>,
        "Du, Julie" <julie.du@...el.com>,
        "Chen, Yu C" <yu.c.chen@...el.com>,
        "Li, Aubrey" <aubrey.li@...el.com>,
        "Tang, Feng" <feng.tang@...el.com>, Rui Zhang <rui.zhang@...el.com>
Subject: Re: [sched/fair] 0b0695f2b3: phoronix-test-suite.compress-gzip.0.seconds
 19.8% regression

On Thu, 4 Jun 2020 at 10:57, Mel Gorman <mgorman@...e.de> wrote:
>
> On Wed, Jun 03, 2020 at 07:06:18PM +0200, Vincent Guittot wrote:
> > > still exists, just the gap becomes smaller -
> > > release         run1    run2
> > > v5.4            4.32    4.3     <-- little change comparing to above
> > > v5.5            5.04    5.06    <-- improves
> > > v5.7-rc7        4.79    4.78
> > > v5.7            4.77    4.77
> > >
> > > I also attached turbostat data as attached.
> >
> > Thanks for the test results and the turbo stats figures.
> > The outcomes are not as obvious as I would have expected. The
> > performance difference for v5.5 and v5.7 when C6 and above are
> > disabled tends to confirm that the idle state is impacting the
> > performance but the difference still remain.
> > Regarding turbostat output, the 1st main difference is the number of
> > time the CPUs entered idle state:
> > v5.4 run1 : 587252+905317+367732+859828+108+332436+110+217=3053000
> > v5.7 run1 : 807623+639635+466723+1298557+108+283548+63+156=3496413
> > which is +14% of entering idle.
> > This is even more obvious on v5.5 run1:
> > 761950+1320362+1681750+682042+91+304755+79+243=4751272 which is +55%
> > of entering idle
> >
> > We have a similar ratio without c6 and above c-state between v5.4 and
> > v5.7 and the ratio has decreased to +22% between v5.4 and v5.5.
> >
> > So this tends to confirm my assumption that tasks are more spread and
> > this generates more enter/leave cpuidle. I still need to think about
> > how to balance this
> >
>
> I have not looked into the data in depth but it's worth noting that
> cpuidle changed the time a CPU spent polling before entering a C state
> within the same window.  See 36fcb4292473 ("cpuidle: use first valid target
> residency as poll time") as an example where poll time went from hundreds
> of nanoseconds to single digits depending on the machine. We used to poll
> for up to a tick before entering idle. I'm not saying whether it's good
> or bad but it certainly can have a big impact on how often a CPU enters
> "true idle in a C state" as opposed to switching to the idle task (swapper)
> for some house keeping.

Thanks. I will have a look

>
> Where things get fun is that the scheduler can make this more or less
> obvious depending on its decisions. If tasks are bouncing like crazy around
> a socket, the load balancer is shifting tasks like crazy or the scheduler
> is stacking tasks when it should not then it can potentially perform
> better in a benchmark if it prevents tasks entering a deep idle state.

That's also my idea for the difference in performance

Thanks
>
> --
> Mel Gorman
> SUSE Labs