linux-kernel - Re: [PATCH v3 0/5] Scan for an idle sibling in a single pass

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]

Date:   Fri, 22 Jan 2021 10:30:52 +0100
From:   Vincent Guittot <vincent.guittot@...aro.org>
To:     Mel Gorman <mgorman@...hsingularity.net>
Cc:     Peter Zijlstra <peterz@...radead.org>,
        Ingo Molnar <mingo@...hat.com>,
        Li Aubrey <aubrey.li@...ux.intel.com>,
        Qais Yousef <qais.yousef@....com>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v3 0/5] Scan for an idle sibling in a single pass

Hi Mel,

On Tue, 19 Jan 2021 at 13:02, Mel Gorman <mgorman@...hsingularity.net> wrote:
>
> On Tue, Jan 19, 2021 at 12:33:04PM +0100, Vincent Guittot wrote:
> > On Tue, 19 Jan 2021 at 12:22, Mel Gorman <mgorman@...hsingularity.net> wrote:
> > >
> > > Changelog since v2
> > > o Remove unnecessary parameters
> > > o Update nr during scan only when scanning for cpus
> >
> > Hi Mel,
> >
> > I haven't looked at your previous version mainly because I'm chasing a
> > performance regression on v5.11-rcx which prevents me from testing the
> > impact of your patchset on my !SMT2 system.
> > Will do this as soon as this problem is fixed
> >
>
> Thanks, that would be appreciated as I do not have access to a !SMT2
> system to do my own evaluation.

I have been able to run tests with your patchset on both large arm64
SMT4 system and small arm64 !SMT system and patch 3 is still a source
of regression on both. Decreasing min number of loops to 2 instead of
4 and scaling it with smt weight doesn't seem to be a good option as
regressions disappear when I remove them as I tested with the patch
below

hackbench -l 2560 -g 1 on 8 cores arm64
v5.11-rc4 : 1.355 (+/- 7.96)
+ sis improvement : 1.923 (+/- 25%)
+ the patch below : 1.332 (+/- 4.95)

hackbench -l 2560 -g 256 on 8 cores arm64
v5.11-rc4 : 2.116 (+/- 4.62%)
+ sis improvement : 2.216 (+/- 3.84%)
+ the patch below : 2.113 (+/- 3.01%)

So starting with a min of 2 loops instead of 4 currently and scaling
nr loop with smt weight doesn't seem to be a good option and we should
remove it for now

diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 808e40d0439d..c4de33574e6e 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -6138,7 +6138,7 @@ static inline int select_idle_core(struct
task_struct *p, int core, struct cpuma

 #endif /* CONFIG_SCHED_SMT */

-#define sis_min_cores          2
+#define sis_min_cores          4

 /*
  * Scan the LLC domain for idle CPUs; this is dynamically regulated by
@@ -6176,8 +6176,6 @@ static int select_idle_cpu(struct task_struct
*p, struct sched_domain *sd, int t
                else
                        nr = sis_min_cores;

-               nr *= sched_smt_weight;
-
                time = cpu_clock(this);
        }



>
> --
> Mel Gorman
> SUSE Labs