<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-size:small"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Sep 25, 2021 at 4:26 AM Ralph Siemsen <<a href="mailto:ralph.siemsen@linaro.org">ralph.siemsen@linaro.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Fri, Sep 24, 2021 at 08:26:00PM +0200, Cyril Hrubis wrote:<br>
<br>
>That is strange, for me the tmpfs starts to return ENOSPC when the<br>
>system is getting low on memory.<br>
<br>
I've repeated the tests, now with kernel 4.19.198 instead of 5.10.y.<br>
<br>
1) LTP 20210524<br>
In the case of tmpfs, it got as far as mntpoint/file4 size 70310993,<br>
before returning ENOSPC. It seems it wrote about 134MB in total,<br>
which roughly matches the amount of free memory on my system.<br>
--> PASS<br>
<br>
2) Latest commit 443cbc1039f5 ("hugeshmat04: try to find unmapped range for test")<br>
tst_test.c:903: TINFO: Limiting tmpfs size to 512MB<br>
OOM during tmpfs after mntpoint/file6 size 90739786<br>
Note the total written to tmpfs adds up to approx 225MB, which does<br>
not make sense -- this would be all memory except kernel itself.<br>
--> FAIL<br>
<br>
3) Revert commit 7338156ac ("increase the fallocate and defallocate size")<br>
Exactly the same behaviour as case 2)<br>
--> FAIL<br>
<br>
4) Remove .dev_min_size from fallocate05.c<br>
tst_test.c:903: TINFO: Limiting tmpfs size to 256MB<br>
Otherwise exactly the same behaviour as case 3)<br>
--> FAIL<br>
<br>
5) Apply Li's patchset (with v2 of the 3rd patch)<br>
Exactly the same behaviour as 4)<br>
--> FAIL<br></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">Can you post the test log for this 5), it shouldn't be similar like 4)</div><div class="gmail_default" style="font-size:small">because we limit tmfs-size to 32MB in this case. and If you didn't remove</div><div class="gmail_default" style="font-size:small">.dev_min_size=512, it should be skip tmpfs test on your 153MB MemAva</div><div class="gmail_default" style="font-size:small">machine. </div><br></div><div><div class="gmail_default" style="font-size:small">With remove .dev_min_size=512 from fallocate05 in situation 5).</div></div><div><div class="gmail_default" style="font-size:small">If it is still OOM with 32MB tmpfs-size, I tend to agree with Cyril that is</div><div class="gmail_default" style="font-size:small">very likely you hit a kernel problem or configure issue.</div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
>Also if that one fails as well it's likely that something is wrong at<br>
>your side.<br>
<br>
Well, this is certainly possible, although there are no intentional <br>
changes in the kernel (esp filesystems). Only drivers for flash, <br>
architecture support, etc. One possible option would be to try testing a <br>
generic ARM kernel under qemu, to see if we can reproduce it there.<br>
<br>
Note however that case 1) worked, while the others fail. So evidently <br>
the way that userspace "tickles" the kernel matters. I also previously <br>
used much older LTP 20200120 and did not have the problem either.<br>
<br>
Thanks again for your time,<br>
Ralph<br>
<br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div>Regards,<br></div><div>Li Wang<br></div></div></div></div>