On 20/04/2026 10:19, Mike Rapoport wrote: > Hi Ryan, > > On Mon, Apr 20, 2026 at 09:37:03AM +0100, Ryan Roberts wrote: >> On 06/04/2026 15:16, Mike Rapoport wrote: >>> From: "Mike Rapoport (Microsoft)" <[email protected]> >>> >>> Hi, >>> >>> There's a lot of dancing around HugeTLB settings in run_vmtests.sh. >>> Some test need just a few default huge pages, some require at least 256 MB, >>> and >>> some just skip lots of tests if huge pages of all supported sizes are not >>> available. >>> >>> The goal of this set is to make tests deal with HugeTLB setup and teardown. >> >> Hi Mike, >> >> I haven't had a chance to review this series properly, but the intent >> certainly >> seems extremely valuable! >> >> I thought I'd share some configuration magic that I always use when running >> on >> arm64. Appologies if I'm teaching you to suck eggs... >> >> arm64 supports multiple hugetlb sizes and (at least in the past) the magic in >> run_vmtests.sh only reserves for the default size. As a consequence, >> whenever I >> run these tests on arm64, I always boot with: >> >> hugepagesz=1G hugepages=0:2,1:2 >> hugepagesz=32M hugepages=0:2,1:2 >> default_hugepagesz=2M hugepages=0:64,1:64 >> hugepagesz=64K hugepages=0:2,1:2 >> >> Which reserves 2 pages of each supported non-default size in each of 2 NUMA >> nodes, and 64 of the default size in each NUMA node. (This would need >> adjusting >> if using a different base page size). >> >> My recollection is that this effectively overrides what the script was doing >> and >> is sufficient to make all hugetlb tests run for all hugepage sizes. > > My goal is to let the tests themself set up the right hugetlb configuration > without forcing it neither in command line nor in the wrapper scripts. > > On x86 I can run all the tests in a virtio-ng VM with two nodes and no > kernel command line overrides. I suppose that should work on arm64 too. > > There are some additional settings that such a VM would need to avoid > skipping tests that presume swap or a real filesystem, but that's more of > virtio-ng limitation. > >> If it's possible to get this non-default hugepage size reservation logic into >> the tests themselves, this will make the mm selftests much easier to run on >> arm64 with full coverage. > > That's what the second half of series do. E.g for cow tests: > > https://lore.kernel.org/linux-mm/[email protected]/T/#m62f23b835061449bc6249afacf993bb32ea11234
Ahh, excellent; you're already considering the non-default sizes. I'll get back in my box :) > >> Another observation is that "secretmem.enable" is currently needed on the >> cmdline to enable secretmem so that the associated tests run. Not sure what >> can >> be done to make that simpler? > > Looks like you're testing really old kernels :) > The secretmem default changed to "enabled" from 6.5 ;-) Good to know; I created my scripts/environment pre-6.5, so that's just historical baggage on my part, I guess. > >> And there are tests that depend on having more than 1 NUMA node; I always run >> under QEMU with 2 emulated NUMA nodes. I guess that's really just a property >> of >> the HW, so nothing to be done from the test harness. > > Right, test harness can't do much about it. It's either run in a virtual > machines with 2 (or more) nodes or enable NUMA emulation in the kernel > configuration and the kernel command line. ACK Thanks again for this improvement! > >> Thanks, >> Ryan >
