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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20251201163015.1438580-1-joshua.hahnjy@gmail.com>
Date: Mon,  1 Dec 2025 08:30:14 -0800
From: Joshua Hahn <joshua.hahnjy@...il.com>
To: Gregory Price <gourry@...rry.net>
Cc: linux-mm@...ck.org,
	akpm@...ux-foundation.org,
	kernel-team@...a.com,
	vbabka@...e.cz,
	surenb@...gle.com,
	mhocko@...e.com,
	jackmanb@...gle.com,
	hannes@...xchg.org,
	ziy@...dia.com,
	linux-kernel@...r.kernel.org,
	David Hildenbrand <david@...hat.com>,
	Wei Yang <richard.weiyang@...il.com>,
	Oscar Salvador <osalvador@...e.de>,
	David Rientjes <rientjes@...gle.com>
Subject: Re: [PATCH v3] page_alloc: allow migration of smaller hugepages during contig_alloc

On Fri, 21 Nov 2025 14:15:40 -0500 Gregory Price <gourry@...rry.net> wrote:

> We presently skip regions with hugepages entirely when trying to do
> contiguous page allocation.  Instead, if hugepage migration is enabled,
> consider regions with hugepages smaller than the target contiguous
> allocation request as valid targets for allocation.
> 
> isolate_migrate_pages_block() already expects requests with hugepages
> to originate from alloc_contig, and hugetlb code also does a migratable
> check when isolating in folio_isolate_hugetlb().
> 
> Suggested-by: David Hildenbrand <david@...hat.com>
> Signed-off-by: Gregory Price <gourry@...rry.net>
> Reviewed-by: Zi Yan <ziy@...dia.com>
> Reviewed-by: Wei Yang <richard.weiyang@...il.com>
> Reviewed-by: Oscar Salvador <osalvador@...e.de>
> Acked-by: David Rientjes <rientjes@...gle.com>
> Acked-by: David Hildenbrand <david@...hat.com>

Hello folks, sorry for arriving late to the party, it seems like the patch
has gotten a lot of reviews already. I thought I would stop by to share
some simple testing that I've done: On a machine with 62GiB memory, I tried to
see if I could allocate a bunch of 2MB hugeTLB pages, then allocate 1GB hugeTLB
pages on top to see if that attempt would succeed.

To test this, I made a really simple setup:
1. Allocate 48GB worth of 2MB hugeTLB pages (24576)
2. Allocate 4 1G hugeTLB pages

Before this patch, I get 0 1G hugeTLB pages.
After this patch, I can get all 4 requested 1G hugeTLB pages!

I would share the script, but it really is just as simple as echoing 24576
and 4 to .../hugepages-{2048kB, 1048576kB}/nr_hugepages, respsectively.
If you want to reproduce this at home, you might have to change how many
2MB pages to allocate to see this difference, depending on the size of your
machine.

With this, please feel free to add:
Tested-by: Joshua Hahn <joshua.hahnjy@...il.com>

Have a great day, everyone!
Joshua

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ