hugetlb: prioritize surplus allocation from current node
authorKoichiro Den <koichiro.den@canonical.com>
Wed, 4 Dec 2024 16:55:03 +0000 (01:55 +0900)
committerAndrew Morton <akpm@linux-foundation.org>
Tue, 14 Jan 2025 06:40:46 +0000 (22:40 -0800)
commitd0f14f7ee0e2d5df447d54487ae0c3aee5a7208f
treede5d22de711045c61df63d7355bbe7b59b14de13
parentd5ea5e5e50dffd13fccedb690a0a1f27be56191a
hugetlb: prioritize surplus allocation from current node

Previously, surplus allocations triggered by mmap were typically made from
the node where the process was running.  On a page fault, the area was
reliably dequeued from the hugepage_freelists for that node.  However,
since commit 003af997c8a9 ("hugetlb: force allocating surplus hugepages on
mempolicy allowed nodes"), dequeue_hugetlb_folio_vma() may fall back to
other nodes unnecessarily even if there is no MPOL_BIND policy, causing
folios to be dequeued from nodes other than the current one.

Also, allocating from the node where the current process is running is
likely to result in a performance win, as mmap-ing processes often touch
the area not so long after allocation.  This change minimizes surprises
for users relying on the previous behavior while maintaining the benefit
introduced by the commit.

So, prioritize the node the current process is running on when possible.

Link: https://lkml.kernel.org/r/20241204165503.628784-1-koichiro.den@canonical.com
Signed-off-by: Koichiro Den <koichiro.den@canonical.com>
Acked-by: Aristeu Rozanski <aris@ruivo.org>
Cc: Aristeu Rozanski <aris@redhat.com>
Cc: David Hildenbrand <david@redhat.com>
Cc: Muchun Song <muchun.song@linux.dev>
Cc: Vishal Moola (Oracle) <vishal.moola@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
mm/hugetlb.c