linux-kernel - Re: [PATCH v3 5/7] sched: SIS_CORE to disable idle core search

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: <12402fea-7b87-8c4d-9485-53f973c38654@oracle.com>
Date:   Mon, 1 Jul 2019 13:37:13 -0700
From:   Subhra Mazumdar <subhra.mazumdar@...cle.com>
To:     Parth Shah <parth@...ux.ibm.com>, linux-kernel@...r.kernel.org
Cc:     peterz@...radead.org, mingo@...hat.com, tglx@...utronix.de,
        steven.sistare@...cle.com, dhaval.giani@...cle.com,
        daniel.lezcano@...aro.org, vincent.guittot@...aro.org,
        viresh.kumar@...aro.org, tim.c.chen@...ux.intel.com,
        mgorman@...hsingularity.net
Subject: Re: [PATCH v3 5/7] sched: SIS_CORE to disable idle core search


>>> Also, systems like POWER9 has sd_llc as a pair of core only. So it
>>> won't benefit from the limits and hence also hiding your code in select_idle_cpu
>>> behind static keys will be much preferred.
>> If it doesn't hurt then I don't see the point.
>>
> So these is the result from POWER9 system with your patches:
> System configuration: 2 Socket, 44 cores, 176 CPUs
>
> Experiment setup:
> ===========
> => Setup 1:
> - 44 tasks doing just while(1), this is to make select_idle_core return -1 most times
> - perf bench sched messaging -g 1 -l 1000000
> +-----------+--------+--------------+--------+
> | Baseline  | stddev |    Patch     | stddev |
> +-----------+--------+--------------+--------+
> |       135 |   3.21 | 158(-17.03%) |   4.69 |
> +-----------+--------+--------------+--------+
>
> => Setup 2:
> - schbench -m44 -t 1
> +=======+==========+=========+=========+==========+
> | %ile  | Baseline | stddev  |  patch  |  stddev  |
> +=======+==========+=========+=========+==========+
> |    50 |       10 |    3.49 |      10 |     2.29 |
> +-------+----------+---------+---------+----------+
> |    95 |      467 |    4.47 |     469 |     0.81 |
> +-------+----------+---------+---------+----------+
> |    99 |      571 |   21.32 |     584 |    18.69 |
> +-------+----------+---------+---------+----------+
> |  99.5 |      629 |   30.05 |     641 |    20.95 |
> +-------+----------+---------+---------+----------+
> |  99.9 |      780 |   40.38 |     773 |     44.2 |
> +-------+----------+---------+---------+----------+
>
> I guess it doesn't make much difference in schbench results but hackbench (perf bench)
> seems to have an observable regression.
>
>
> Best,
> Parth
>
If POWER9 sd_llc has only 2 cores, the behavior shouldn't change much with
the select_idle_cpu changes as the limits are 1 and 2 core. Previously the
lower bound was 4 cpus and upper bound calculated by the prop. Now it is
1 core (4 cpus on SMT4) and upper bound 2 cores. Could it be the extra
computation of cpumask_weight causing the regression rather than the
sliding window itself (one way to check this would be hardcode 4 in place
of topology_sibling_weight)? Or is it the L1 cache coherency? I am a bit
suprised because SPARC SMT8 which has more cores in sd_llc and L1 cache per
core showed improvement with Hackbench.

Thanks,
Subhra