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

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]

Message-ID: <aOyxle8OJPMKlVWX@localhost.localdomain>
Date: Mon, 13 Oct 2025 10:00:21 +0200
From: Oscar Salvador <osalvador@...e.de>
To: Usama Arif <usamaarif642@...il.com>
Cc: muchun.song@...ux.dev, david@...hat.com,
	Andrew Morton <akpm@...ux-foundation.org>, shakeel.butt@...ux.dev,
	linux-mm@...ck.org, hannes@...xchg.org, riel@...riel.com,
	kas@...nel.org, linux-kernel@...r.kernel.org, kernel-team@...a.com
Subject: Re: [PATCH v2 2/2] mm/hugetlb: allow overcommitting gigantic
 hugepages

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@...il.com>

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:

Acked-by: Oscar Salvador <osalvador@...e.de>

 

-- 
Oscar Salvador
SUSE Labs