On Wed, Apr 01, 2026 at 03:53:30PM -0700, Dave Jiang wrote: > > > On 3/31/26 9:49 PM, Alison Schofield wrote: > > The mmap test allocates a 1 GiB file and exercises a matrix of mmap > > flag combinations across ext4+dax and xfs+dax, performing multiple > > full-range read and write passes for each case. > > > > The coverage of this test comes from the mmap modes and access > > patterns it exercises (MAP_SHARED vs MAP_PRIVATE, MAP_POPULATE, > > mlock/munlock, and read-only mappings), not from the size of the > > mapping itself. These behaviors are not size-dependent, and no test > > assertions rely on a 1 GiB mapping. > > > > Long CI runtimes prompted a closer look at this test, but the > > reduction stands on its own merits: a 256 MiB mapping still spans many > > PMD (2 MiB) DAX mappings and exercises the same access patterns, while > > avoiding unnecessary work in each test case. > > No excercise of tests against 1GB page? > > DJ
Right on cue, Dave! That is what I need to learn about. Reducing mmap.sh to 256 MiB would rule out any 1 GiB mapping coverage in this test. Looking at the mmap test cases, I'm not able to determine if the 1 GiB was intentional or required for the behaviors under test. More generally, mmap.sh is not the only case. Several of the DAX tests use "fallocate -l 1GiB", and I'm trying to understand whether that size is preserving specific coverage or is just inherited convention. I’ve appended a quick grep below for reference. What I need to understand is whether 1 GiB is essential here, and if so what behavior it is meant to exercise. In comparing tests, the impact of reducing the file size in mmap.sh was significant, while the effect in dax-ext4.sh and dax-xfs.sh was much smaller. That suggests the runtime sensitivity is specific to how mmap.sh exercises the file, rather than a general property of all tests using "fallocate -l 1GiB". In mmap.c, each test case maps the full file and performs full-range read and/or write passes across the entire mapping with various mmap flag combinations. That pattern makes the cost scale directly with the size of the mapping for each case, which would explain why mmap.sh is particularly sensitive to the file size. I also tried reducing the 3 full-range iterations in mmap.c to 1 while keeping the file at 1 GiB. That saved a bit, but mostly suggests that the cost is tied more to the size of the mapping itself across the per-case mmap/populate/lock paths than to repeated read/write passes. I need to understand what coverage we need with DAX and 1 GiB and make sure that is exercised intentionally rather than incidentally. (And, yes, I also hope to cut out needless runtime.) All the DAX unit test fallocates: ax-ext4.sh: fallocate -l 1GiB $MNT/$FILE dax-ext4.sh: fallocate -l 1GiB $MNT/$FILE dax-ext4.sh: fallocate -l 1GiB $MNT/$FILE dax-ext4.sh: fallocate -l 1GiB $MNT/$FILE dax.sh: fallocate -l 1GiB $MNT/$FILE dax.sh: fallocate -l 1GiB $MNT/$FILE dax.sh: fallocate -l 1GiB $MNT/$FILE dax.sh: fallocate -l 1GiB $MNT/$FILE dax-xfs.sh: fallocate -l 1GiB $MNT/$FILE dax-xfs.sh: fallocate -l 1GiB $MNT/$FILE dax-xfs.sh: fallocate -l 1GiB $MNT/$FILE dax-xfs.sh: fallocate -l 1GiB $MNT/$FILE mmap.sh:fallocate -l 1GiB $MNT/$FILE mmap.sh:fallocate -l 1GiB $MNT/$FILE > > > > > > Signed-off-by: Alison Schofield <[email protected]> > > --- > > test/mmap.sh | 4 ++-- > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > diff --git a/test/mmap.sh b/test/mmap.sh > > index 7d0053da0e1a..c517d5b0f50b 100755 > > --- a/test/mmap.sh > > +++ b/test/mmap.sh > > @@ -59,12 +59,12 @@ rc=1 > > > > mkfs.ext4 $DEV > > mount $DEV $MNT -o dax > > -fallocate -l 1GiB $MNT/$FILE > > +fallocate -l 256MiB $MNT/$FILE > > test_mmap > > umount $MNT > > > > mkfs.xfs -f $DEV -m reflink=0 > > mount $DEV $MNT -o dax > > -fallocate -l 1GiB $MNT/$FILE > > +fallocate -l 256MiB $MNT/$FILE > > test_mmap > > umount $MNT >
