• Barry Song's avatar
    sched/fair: Scan cluster before scanning LLC in wake-up path · 8881e163
    Barry Song authored
    For platforms having clusters like Kunpeng920, CPUs within the same cluster
    have lower latency when synchronizing and accessing shared resources like
    cache. Thus, this patch tries to find an idle cpu within the cluster of the
    target CPU before scanning the whole LLC to gain lower latency. This
    will be implemented in 2 steps in select_idle_sibling():
    1. When the prev_cpu/recent_used_cpu are good wakeup candidates, use them
       if they're sharing cluster with the target CPU. Otherwise trying to
       scan for an idle CPU in the target's cluster.
    2. Scanning the cluster prior to the LLC of the target CPU for an
       idle CPU to wakeup.
    
    Testing has been done on Kunpeng920 by pinning tasks to one numa and two
    numa. On Kunpeng920, Each numa has 8 clusters and each cluster has 4 CPUs.
    
    With this patch, We noticed enhancement on tbench and netperf within one
    numa or cross two numa on top of tip-sched-core commit
    9b46f1abc6d4 ("sched/debug: Print 'tgid' in sched_show_task()")
    
    tbench results (node 0):
                baseline                     patched
      1:        327.2833        372.4623 (   13.80%)
      4:       1320.5933       1479.8833 (   12.06%)
      8:       2638.4867       2921.5267 (   10.73%)
     16:       5282.7133       5891.5633 (   11.53%)
     32:       9810.6733       9877.3400 (    0.68%)
     64:       7408.9367       7447.9900 (    0.53%)
    128:       6203.2600       6191.6500 (   -0.19%)
    tbench results (node 0-1):
                baseline                     patched
      1:        332.0433        372.7223 (   12.25%)
      4:       1325.4667       1477.6733 (   11.48%)
      8:       2622.9433       2897.9967 (   10.49%)
     16:       5218.6100       5878.2967 (   12.64%)
     32:      10211.7000      11494.4000 (   12.56%)
     64:      13313.7333      16740.0333 (   25.74%)
    128:      13959.1000      14533.9000 (    4.12%)
    
    netperf results TCP_RR (node 0):
                baseline                     patched
      1:      76546.5033      90649.9867 (   18.42%)
      4:      77292.4450      90932.7175 (   17.65%)
      8:      77367.7254      90882.3467 (   17.47%)
     16:      78519.9048      90938.8344 (   15.82%)
     32:      72169.5035      72851.6730 (    0.95%)
     64:      25911.2457      25882.2315 (   -0.11%)
    128:      10752.6572      10768.6038 (    0.15%)
    
    netperf results TCP_RR (node 0-1):
                baseline                     patched
      1:      76857.6667      90892.2767 (   18.26%)
      4:      78236.6475      90767.3017 (   16.02%)
      8:      77929.6096      90684.1633 (   16.37%)
     16:      77438.5873      90502.5787 (   16.87%)
     32:      74205.6635      88301.5612 (   19.00%)
     64:      69827.8535      71787.6706 (    2.81%)
    128:      25281.4366      25771.3023 (    1.94%)
    
    netperf results UDP_RR (node 0):
                baseline                     patched
      1:      96869.8400     110800.8467 (   14.38%)
      4:      97744.9750     109680.5425 (   12.21%)
      8:      98783.9863     110409.9637 (   11.77%)
     16:      99575.0235     110636.2435 (   11.11%)
     32:      95044.7250      97622.8887 (    2.71%)
     64:      32925.2146      32644.4991 (   -0.85%)
    128:      12859.2343      12824.0051 (   -0.27%)
    
    netperf results UDP_RR (node 0-1):
                baseline                     patched
      1:      97202.4733     110190.1200 (   13.36%)
      4:      95954.0558     106245.7258 (   10.73%)
      8:      96277.1958     105206.5304 (    9.27%)
     16:      97692.7810     107927.2125 (   10.48%)
     32:      79999.6702     103550.2999 (   29.44%)
     64:      80592.7413      87284.0856 (    8.30%)
    128:      27701.5770      29914.5820 (    7.99%)
    
    Note neither Kunpeng920 nor x86 Jacobsville supports SMT, so the SMT branch
    in the code has not been tested but it supposed to work.
    
    Chen Yu also noticed this will improve the performance of tbench and
    netperf on a 24 CPUs Jacobsville machine, there are 4 CPUs in one
    cluster sharing L2 Cache.
    
    [https://lore.kernel.org/lkml/Ytfjs+m1kUs0ScSn@worktop.programming.kicks-ass.net]
    Suggested-by: default avatarPeter Zijlstra <peterz@infradead.org>
    Signed-off-by: default avatarBarry Song <song.bao.hua@hisilicon.com>
    Signed-off-by: default avatarYicong Yang <yangyicong@hisilicon.com>
    Signed-off-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
    Reviewed-by: default avatarTim Chen <tim.c.chen@linux.intel.com>
    Reviewed-by: default avatarChen Yu <yu.c.chen@intel.com>
    Reviewed-by: default avatarGautham R. Shenoy <gautham.shenoy@amd.com>
    Reviewed-by: default avatarVincent Guittot <vincent.guittot@linaro.org>
    Tested-and-reviewed-by: default avatarChen Yu <yu.c.chen@intel.com>
    Tested-by: default avatarYicong Yang <yangyicong@hisilicon.com>
    Link: https://lkml.kernel.org/r/20231019033323.54147-3-yangyicong@huawei.com
    8881e163
fair.c 349 KB