* Mel Gorman <mgorman@xxxxxxxxxxxxxxxxxxx> [2018-10-01 11:05:24]: > Rate limiting of page migrations due to automatic NUMA balancing was > introduced to mitigate the worst-case scenario of migrating at high > frequency due to false sharing or slowly ping-ponging between nodes. > Since then, a lot of effort was spent on correctly identifying these > pages and avoiding unnecessary migrations and the safety net may no longer > be required. > > Jirka Hladky reported a regression in 4.17 due to a scheduler patch that > avoids spreading STREAM tasks wide prematurely. However, once the task > was properly placed, it delayed migrating the memory due to rate limiting. > Increasing the limit fixed the problem for him. > > Currently, the limit is hard-coded and does not account for the real > capabilities of the hardware. Even if an estimate was attempted, it would > not properly account for the number of memory controllers and it could > not account for the amount of bandwidth used for normal accesses. Rather > than fudging, this patch simply eliminates the rate limiting. > > However, Jirka reports that a STREAM configuration using multiple > processes achieved similar performance to 4.16. In local tests, this patch > improved performance of STREAM relative to the baseline but it is somewhat > machine-dependent. Most workloads show little or not performance difference > implying that there is not a heavily reliance on the throttling mechanism > and it is safe to remove. > > STREAM on 2-socket machine > 4.19.0-rc5 4.19.0-rc5 > numab-v1r1 noratelimit-v1r1 > MB/sec copy 43298.52 ( 0.00%) 44673.38 ( 3.18%) > MB/sec scale 30115.06 ( 0.00%) 31293.06 ( 3.91%) > MB/sec add 32825.12 ( 0.00%) 34883.62 ( 6.27%) > MB/sec triad 32549.52 ( 0.00%) 34906.60 ( 7.24% > > Signed-off-by: Mel Gorman <mgorman@xxxxxxxxxxxxxxxxxxx> > --- Reviewed-by: Srikar Dronamraju <srikar@xxxxxxxxxxxxxxxxxx> -- Thanks and Regards Srikar Dronamraju
