lkml.org 
[lkml]   [2019]   [Jul]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH v3 5/7] sched: SIS_CORE to disable idle core search
From
Date

>>> 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

\
 
 \ /
  Last update: 2019-07-01 22:44    [W:0.073 / U:0.472 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site