Re: [PATCH v2 2/2] mm/hugetlb: allow overcommitting gigantic hugepages

[Kefeng Wang]

On 2025/10/13 16:00, Oscar Salvador wrote:
> On Thu, Oct 09, 2025 at 06:24:31PM +0100, Usama Arif wrote:
> > Currently, gigantic hugepages cannot use the overcommit mechanism
> > (nr_overcommit_hugepages), forcing users to permanently reserve memory via
> > nr_hugepages even when pages might not be actively used.
> >
> > The restriction was added in 2011 [1], which was before there was support
> > for reserving 1G hugepages at runtime.
> > Remove this blanket restriction on gigantic hugepage overcommit.
> > This will bring the same benefits to gigantic pages as hugepages:
> >
> > - Memory is only taken out of regular use when actually needed
> > - Unused surplus pages can be returned to the system
> > - Better memory utilization, especially with CMA backing which can
> >    significantly increase the changes of hugepage allocation
> >
> > Without this patch:
> > echo 3 > /sys/kernel/mm/hugepages/hugepages-1048576kB/nr_overcommit_hugepages
> > bash: echo: write error: Invalid argument
> >
> > With this patch:
> > echo 3 > /sys/kernel/mm/hugepages/hugepages-1048576kB/nr_overcommit_hugepages
> > ./mmap_hugetlb_test
> > Successfully allocated huge pages at address: 0x7f9d40000000
> >
> > cat mmap_hugetlb_test.c
> > ...
> >      unsigned long ALLOC_SIZE = 3 * (unsigned long) HUGE_PAGE_SIZE;
> >      addr = mmap(NULL,
> >                  ALLOC_SIZE, // 3GB
> >                  PROT_READ | PROT_WRITE,
> >                  MAP_PRIVATE | MAP_ANONYMOUS | MAP_HUGETLB | MAP_HUGE_1GB,
> >                  -1,
> >                  0);
> >
> >      if (addr == MAP_FAILED) {
> >          fprintf(stderr, "mmap failed: %s\n", strerror(errno));
> >          return 1;
> >      }
> >      printf("Successfully allocated huge pages at address: %p\n", addr);
> > ...
> >
> > [1] https://git.zx2c4.com/linux-rng/commit/mm/hugetlb.c?id=adbe8726dc2a3805630d517270db17e3af86e526
> >
> > Signed-off-by: Usama Arif <usamaarif642@xxxxxxxxx>

Reviewed-by: Kefeng Wang <wangkefeng.wang@xxxxxxxxxx>

> I guess nobody bothered to do this after we added support for 1GB hugepages because
> creating those at runtime is tricky, and in my experience, almost everybody reserves
> those at boot time.
> But I do not have objections to make them behave as normal hugepages:

We do have cases to allocate 1G hugepages at runtime and we enable 
migrate 1G hugepages in alloc_migrate_hugetlb_folio() too :)

I will send a patch to enable gigantic pages migration based on this one.


> Acked-by: Oscar Salvador <osalvador@xxxxxxx>
>
>