[LTP] [RFC PATCH] fallocate05: increase the fallocate and defallocate size

[Ralph Siemsen]

On Fri, Sep 24, 2021 at 08:26:00PM +0200, Cyril Hrubis wrote:

>That is strange, for me the tmpfs starts to return ENOSPC when the
>system is getting low on memory.

I've repeated the tests, now with kernel 4.19.198 instead of 5.10.y.

1) LTP 20210524
   In the case of tmpfs, it got as far as mntpoint/file4 size 70310993,
   before returning ENOSPC. It seems it wrote about 134MB in total,
   which roughly matches the amount of free memory on my system.
   --> PASS

2) Latest commit 443cbc1039f5 ("hugeshmat04: try to find unmapped range for test")
   tst_test.c:903: TINFO: Limiting tmpfs size to 512MB
   OOM during tmpfs after mntpoint/file6 size 90739786
   Note the total written to tmpfs adds up to approx 225MB, which does
   not make sense -- this would be all memory except kernel itself.
   --> FAIL

3) Revert commit 7338156ac ("increase the fallocate and defallocate size")
    Exactly the same behaviour as case 2)
    --> FAIL

4) Remove .dev_min_size from fallocate05.c
    tst_test.c:903: TINFO: Limiting tmpfs size to 256MB
    Otherwise exactly the same behaviour as case 3)
    --> FAIL

5) Apply Li's patchset (with v2 of the 3rd patch)
    Exactly the same behaviour as 4)
    --> FAIL

>Also if that one fails as well it's likely that something is wrong at
>your side.

Well, this is certainly possible, although there are no intentional 
changes in the kernel (esp filesystems). Only drivers for flash, 
architecture support, etc. One possible option would be to try testing a 
generic ARM kernel under qemu, to see if we can reproduce it there.

Note however that case 1) worked, while the others fail. So evidently 
the way that userspace "tickles" the kernel matters. I also previously 
used much older LTP 20200120 and did not have the problem either.

Thanks again for your time,
Ralph