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

[Li Wang]

On Sat, Sep 25, 2021 at 4:26 AM Ralph Siemsen <ralph.siemsen@linaro.org>
wrote:

> 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
>

Can you post the test log for this 5), it shouldn't be similar like 4)
because we limit tmfs-size to 32MB in this case. and If you didn't remove
.dev_min_size=512, it should be skip tmpfs test on your 153MB MemAva
machine.

With remove .dev_min_size=512 from fallocate05 in situation 5).
If it is still OOM with 32MB tmpfs-size, I tend to agree with Cyril that is
very likely you hit a kernel problem or configure issue.



>
> >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
>
>

-- 
Regards,
Li Wang
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linux.it/pipermail/ltp/attachments/20210926/1bab3b65/attachment.htm>