Messages in this thread | | | Date | Wed, 9 May 2018 19:04:51 -0700 | From | Srikar Dronamraju <> | Subject | Re: [PATCH] Revert "sched/numa: Delay retrying placement for automatic NUMA balance after wake_affine()" |
| |
* Mel Gorman <mgorman@techsingularity.net> [2018-05-09 17:31:15]:
> This reverts commit 7347fc87dfe6b7315e74310ee1243dc222c68086. > > Srikar Dronamra pointed out that while the commit in question did show > a performance improvement on ppc64, it did so at the cost of disabling > active CPU migration by automatic NUMA balancing which was not the intent. > The issue was that a serious flaw in the logic failed to ever active balance > if SD_WAKE_AFFINE was disabled on scheduler domains. Even when it's enabled, > the logic is still bizarre and against the original intent. > > Investigation showed that fixing the patch in either the way he suggested, > using the correct comparison for jiffies values or introducing a new > numa_migrate_deferred variable in task_struct all perform similarly to a > revert with a mix of gains and losses depending on the workload, machine > and socket count. > > The original intent of the commit was to handle a problem whereby > wake_affine, idle balancing and automatic NUMA balancing disagree on the > appropriate placement for a task. This was particularly true for cases where > a single task was a massive waker of tasks but where wake_wide logic did > not apply. This was particularly noticeable when a futex (a barrier) woke > all worker threads and tried pulling the wakees to the waker nodes. In that > specific case, it could be handled by tuning MPI or openMP appropriately, > but the behavior is not illogical and was worth attempting to fix. However, > the approach was wrong. Given that we're at rc4 and a fix is not obvious, > it's better to play safe, revert this commit and retry later. > > Signed-off-by: Mel Gorman <mgorman@techsingularity.net>
Reviewed-by: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
| |