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 > 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 ;-) > 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. > Thanks, > Ryan -- Sincerely yours, Mike.
