All of lore.kernel.org
 help / color / mirror / Atom feed
From: Muchun Song <muchun.song@linux.dev>
To: Huaisheng Ye <yehuaisheng@open-hieco.net>
Cc: osalvador@suse.de, linux-mm@kvack.org, david@kernel.org,
	akpm@linux-foundation.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] mm/hugetlb: account for allowed nodes when gathering surplus pages
Date: Thu, 10 Sep 2026 16:48:56 +0800	[thread overview]
Message-ID: <8A0F6014-4E2C-4F07-9732-2DF32418B986@linux.dev> (raw)
In-Reply-To: <20260909074642.7308-1-yehuaisheng@open-hieco.net>



> On Sep 9, 2026, at 15:46, Huaisheng Ye <yehuaisheng@open-hieco.net> wrote:
> 
> Hugetlb reservations are accounted globally, but hugetlb_acct_memory()
> also verifies that the current cpuset and MPOL_BIND policy contain enough
> free huge pages to add a new reservation.
> 
> gather_surplus_pages() calculates its allocation shortfall from the global
> free and reserved counters. If the global pool has enough free pages, but
> those pages reside outside the nodes allowed by the task, it allocates no
> surplus pages. The subsequent allowed_mems_nr() check then rejects the
> reservation and mmap() fails with ENOMEM, even when
> nr_overcommit_hugepages permits allocating surplus pages on the allowed
> nodes.
> 
> Calculate both the global shortfall and the shortfall within the allowed
> nodes, and allocate the larger of the two. Include surplus pages allocated
> outside hugetlb_lock in both calculations when rechecking after reacquiring
> the lock. These pages are constrained by alloc_nodemask, so they satisfy
> both shortages.
> 
> Easy way to reproduce this issue with 2+ NUMA nodes system:
> 
>  # echo 0 > /sys/kernel/mm/hugepages/hugepages-2048kB/nr_hugepage
>  # echo 3 > /sys/devices/system/node/node0/hugepages/hugepages-2048kB/nr_hugepages
>  # echo 1 > /sys/kernel/mm/hugepages/hugepages-2048kB/nr_overcommit_hugepages
>  # cd tools/testing/selftests/mm
>  # numactl --membind=1 ./hugetlb-mmap 2 21
>  TAP version 13
>  # [INFO] detected hugetlb page size: 2048 KiB
>  # [INFO] detected hugetlb page size: 1048576 KiB
>  # 2048 kB hugepages
>  1..2
>  # Mapping 2 Mbytes
>  Bail out! mmap: Cannot allocate memory (12)
>  # Planned tests != run tests (2 != 0)
>  # Totals: pass:0 fail:0 xfail:0 xpass:0 skip:0 error:0
> 
> This fixes hugetlb mappings when, for example, a task runs with
> MPOL_BIND on Node 1 while the existing free huge pages are on Node 0.
> 
> Similar issue also could be found in ltp if the free pages of global pool
> reside outside the nodes allowed by the application.
>  # cd ltp/testcases/kernel/mem/hugetlb/hugemmap/
>  # numactl --cpunodebind=0 --membind=1 ./hugemmap10
> 
> Signed-off-by: Huaisheng Ye <yehuaisheng@open-hieco.net>

Acked-by: Muchun Song <muchun.song@linux.dev>

Thanks.



  reply	other threads:[~2026-09-10  8:49 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-09  7:46 [PATCH] mm/hugetlb: account for allowed nodes when gathering surplus pages Huaisheng Ye
2026-09-10  8:48 ` Muchun Song [this message]
2026-09-10 22:20   ` Andrew Morton
2026-09-11  2:41     ` Muchun Song
2026-09-11  8:19       ` Huaisheng Ye

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=8A0F6014-4E2C-4F07-9732-2DF32418B986@linux.dev \
    --to=muchun.song@linux.dev \
    --cc=akpm@linux-foundation.org \
    --cc=david@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=osalvador@suse.de \
    --cc=yehuaisheng@open-hieco.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.