linux-kernel - Re: [PATCH v4 04/11] sched/fair: rework load

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

Message-ID: <CAKfTPtCVdG1zcd4kyU4d+K_+VdW7TZn+RSDKt4Hk28B366NPOQ@mail.gmail.com>
Date:   Tue, 12 Nov 2019 16:40:20 +0100
From:   Vincent Guittot <vincent.guittot@...aro.org>
To:     Mel Gorman <mgorman@...hsingularity.net>
Cc:     linux-kernel <linux-kernel@...r.kernel.org>,
        Ingo Molnar <mingo@...hat.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Phil Auld <pauld@...hat.com>,
        Valentin Schneider <valentin.schneider@....com>,
        Srikar Dronamraju <srikar@...ux.vnet.ibm.com>,
        Quentin Perret <quentin.perret@....com>,
        Dietmar Eggemann <dietmar.eggemann@....com>,
        Morten Rasmussen <Morten.Rasmussen@....com>,
        Hillf Danton <hdanton@...a.com>,
        Parth Shah <parth@...ux.ibm.com>,
        Rik van Riel <riel@...riel.com>
Subject: Re: [PATCH v4 04/11] sched/fair: rework load_balance

On Tue, 12 Nov 2019 at 16:06, Mel Gorman <mgorman@...hsingularity.net> wrote:
>
> On Tue, Nov 12, 2019 at 11:58:30AM +0100, Vincent Guittot wrote:
> > > This roughly matches what I've seen. The interesting part to me for
> > > netperf is the next section of the report that reports the locality of
> > > numa hints. With netperf on a 2-socket machine, it's generally around
> > > 50% as the client/server are pulled apart. Because netperf is not
> > > heavily memory bound, it doesn't have much impact on the overall
> > > performance but it's good at catching the cross-node migrations.
> >
> > Ok. I didn't want to make my reply too long. I have put them below for
> > the netperf-tcp results:
> >                                         5.3-rc2        5.3-rc2
> >                                             tip      +rwk+fix
> > Ops NUMA alloc hit                  60077762.00    60387907.00
> > Ops NUMA alloc miss                        0.00           0.00
> > Ops NUMA interleave hit                    0.00           0.00
> > Ops NUMA alloc local                60077571.00    60387798.00
> > Ops NUMA base-page range updates        5948.00       17223.00
> > Ops NUMA PTE updates                    5948.00       17223.00
> > Ops NUMA PMD updates                       0.00           0.00
> > Ops NUMA hint faults                    4639.00       14050.00
> > Ops NUMA hint local faults %            2073.00        6515.00
> > Ops NUMA hint local percent               44.69          46.37
> > Ops NUMA pages migrated                 1528.00        4306.00
> > Ops AutoNUMA cost                         23.27          70.45
> >
>
> Thanks -- it was "NUMA hint local percent" I was interested in and the
> 46.37% local hinting faults is likely indicative of the client/server
> being load balanced across SD_NUMA domains without NUMA Balancing being
> aggressive enough to fix it. At least I know I am not just seriously
> unlucky or testing magical machines!

I agree that the collaboration between load balanced across SD_NUMA
level and NUMA balancing should be improved

It's also interesting to notice that the patchset doesn't seem to do
worse than the baseline: 46.37% vs 44.69%

Vincent

>
> --
> Mel Gorman
> SUSE Labs