NACK: [SRU][O/N][PATCH 0/1] Fix LTP hugetlb failure and prevent potential performance degradation

[Koichiro Den]

On Thu, Dec 12, 2024 at 04:46:23PM GMT, Koichiro Den wrote:
> BugLink: https://bugs.launchpad.net/bugs/2089768
> 
> SRU Justification:
> 
> [Impact]
> 
> Since upstream commit 003af997c8a9 ("hugetlb: force allocating surplus
> hugepages on mempolicy allowed nodes"), the LTP hugetlb test case
> 'hugemmap10' has started failing frequently. In some testing environments,
> it fails almost consistently. This occurs because the surplus allocation
> behavior was changed, typically leading to allocations being made on the
> least numbered possible NUMA node, even when allocation from the NUMA node
> on which the current task running is feasible. This not only causes LTP
> test failures but also indicates potential performance degradation.
> 
> This patch restores the previous behavior while preserving the benefits
> introduced by commit 003af997c8a9. It not only reduces LTP test failure
> noise but also prevents performance degradations.
> 
> [Fix]
> 
> The following upstream commit resolves the issue:
> https://lore.kernel.org/all/20241204165503.628784-1-koichiro.den@canonical.com
> It does not currently meet stable criteria, so it's unlikely that it will
> land in upstream stable tree. That is why this SRU patch.
> 
> [Test Plan]
> 
> Run the LTP hugemmap10 and verify that it passes consistently on machines
> where it previously failed. If such machines are not available, compare
> behavior with and without the patch by performing the following steps:
> 1. prepare a machine which has two or more NUMA nodes, each having usable
>    memory
> 2. run hugemmap10 with naively pinning it onto some CPU of NUMA node #1;
>    $ sudo taskset -c {some-cpu-on-node-1} ./hugemmap10
> Without this patch, you will observe consistent failures, while with this
> patch, the issue will disappear.
> 
> [Where problems could occur]
> 
> This change affects only hugetlb. If any regressions are found, they would
> likely impact hugetlb users.
> 
> 
> Koichiro Den (1):
>   hugetlb: prioritize surplus allocation from current node
> 
>  mm/hugetlb.c | 20 +++++++++++++++++---
>  1 file changed, 17 insertions(+), 3 deletions(-)
> 
> -- 
> 2.43.0
> 

NACK by myself. Cleaning up the ML.