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

Reply via email to