Messages in this thread | | | Subject | Re: [PATCH v3 5/7] sched: SIS_CORE to disable idle core search | From | Subhra Mazumdar <> | Date | Mon, 1 Jul 2019 13:37:13 -0700 |
| |
>>> 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
| |