lkml.org 
[lkml]   [2022]   [May]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v3] sched/fair: Introduce SIS_UTIL to search idle CPU based on sum of util_avg
On Tue, May 10, 2022 at 08:41:57PM +0800, Yicong Yang wrote:
> On 2022/4/29 2:24, Chen Yu wrote:
> > @@ -61,6 +61,7 @@ SCHED_FEAT(TTWU_QUEUE, true)
> > * When doing wakeups, attempt to limit superfluous scans of the LLC domain.
> > */
> > SCHED_FEAT(SIS_PROP, true)
> > +SCHED_FEAT(SIS_UTIL, false)
> >
>
> I see you mentioned they're mutually exclusive in the commit, worth a comment here?
>
Yes, previously I thought it could be made mutually exclusive, and Peter has
suggested that we should make SIS_UTIL enabled by default, so later we could
remove SIS_PROP if SIS_UTIL behaves stable. So I assume there is no need to
add comment in the next version now.
> One minor question: nr is updated in load balance so there maybe a delay because of
> interval of load balancing.
Yes, this is a good question. The default interval between two load balance is sd_weight ms,
which is 112ms in my case. This interval was a trade off to reduce cache contention. Besides,
every 1st idle CPU or the balanced CPU in one sched group within the LLC domain has the chance
to launch a periodic load balance, for example, although CPU0 and CPU1's periodic load balance
are both triggered every 112ms, CPU1 could help launch the load balance when CPU0 is not in
load balance work. Consider there are many CPUs in a LLC domain, the 'internal' to launch
the periodic load balance becomes smaller.
> Furthermore, the LLC domain may not be balanced everytime
> if the lowest domain is not LLC, like CLS->LLC. So maybe a bit more delay included.
>
I thought every domain has its chance to launch a load balance, the difference is different
domains have different interval. No?
> The test results is fine and as expected. The improvement of netperf at a heavy load
> condition, compared to your v2 version.
>
Thanks for the test, would you mind if I add Tested-by tag?

thanks,
Chenyu
> Thanks,
> Yicong
>
> TCP_RR node 0-1
> threads
> 16 57559.56667 57930.03333 (+0.64%)
> 32 56373 57754.53333 (+2.45%)
> 64 18831.4 46234.76667 (+145.52%)
> 128 15658.9 19620.26667 (+25.30%)
> 256 7959.896667 8869.013333 (+11.42%)
>
> TCP_RR node 0
> threads
> 16 58389.43333 59026.03333 (+1.09%)
> 32 23779.6 51563.33333 (+116.84%)
> 64 20514.56667 23485.63333 (+14.48%)
> 128 8202.49 9205.483333 (+12.23%)
> 256 3843.163333 4304.8 (+12.01%)
>
> tbench4 node 0-1
> 5.18-rc1 patched
> Hmean 1 299.02 ( 0.00%) 307.73 * 2.91%*
> Hmean 2 597.88 ( 0.00%) 619.10 * 3.55%*
> Hmean 4 1207.11 ( 0.00%) 1239.57 * 2.69%*
> Hmean 8 2406.67 ( 0.00%) 2463.63 * 2.37%*
> Hmean 16 4755.52 ( 0.00%) 4979.46 * 4.71%*
> Hmean 32 9449.01 ( 0.00%) 9709.59 * 2.76%*
> Hmean 64 10538.89 ( 0.00%) 10727.86 * 1.79%*
> Hmean 128 13333.84 ( 0.00%) 14580.63 * 9.35%*
> Hmean 256 11735.24 ( 0.00%) 11737.16 ( 0.02%)
>
> tbench4 node 0
> 5.18-rc1 patched
> Hmean 1 302.26 ( 0.00%) 313.43 * 3.70%*
> Hmean 2 603.87 ( 0.00%) 618.56 * 2.43%*
> Hmean 4 1213.91 ( 0.00%) 1249.63 * 2.94%*
> Hmean 8 2469.72 ( 0.00%) 2527.48 * 2.34%*
> Hmean 16 4980.70 ( 0.00%) 5099.62 * 2.39%*
> Hmean 32 9001.88 ( 0.00%) 9730.27 * 8.09%*
> Hmean 64 7032.07 ( 0.00%) 7691.56 * 9.38%*
> Hmean 128 6037.76 ( 0.00%) 6712.86 * 11.18%*
> Hmean 256 8513.83 ( 0.00%) 9117.79 * 7.09%*
>

\
 
 \ /
  Last update: 2022-05-12 10:16    [W:0.144 / U:1.252 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site