linux-kernel - Re: [PATCH] Revert "sched/numa: Delay retrying placement for automatic NUMA balance after wake

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 9 May 2018 19:04:51 -0700
From:   Srikar Dronamraju <srikar@...ux.vnet.ibm.com>
To:     Mel Gorman <mgorman@...hsingularity.net>
Cc:     mingo@...nel.org, peterz@...radead.org,
        torvalds@...ux-foundation.org, tglx@...utronix.de, hpa@...or.com,
        efault@....de, linux-kernel@...r.kernel.org,
        matt@...eblueprint.co.uk, ggherdovich@...e.cz, mpe@...erman.id.au
Subject: Re: [PATCH] Revert "sched/numa: Delay retrying placement for
 automatic NUMA balance after wake_affine()"

* Mel Gorman <mgorman@...hsingularity.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@...hsingularity.net>


Reviewed-by: Srikar Dronamraju <srikar@...ux.vnet.ibm.com>