<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 Thu, Sep 23, 2021 at 12:52 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">Hello,<br>
<br>
On Wed, Sep 22, 2021 at 04:32:45PM +0200, Cyril Hrubis wrote:<br>
>><br>
>> That try one by one block after filling full of the FS because nobody knows<br>
>> when fails.<br>
>><br>
>> But as you suggested we can do that as well for the previous allocation :).<br>
>><br>
>> So, will you create a patch, or I do that tomorrow?<br>
><br>
>I will not manage today. So either you do it or I can do it tomorrow<br>
>:-).<br>
<br>
I tried making a patch for this, which I can share. But after testing, I <br>
am still seeing OOM. Upon further inspection, it seems to be coming from <br>
tst_fill_fs() function, when operating on a tmpfs.  I see the message:<br>
<br>
tst_test.c:903: TINFO: Limiting tmpfs size to 512MB<br>
<br>
However the machine only has 256MB total, of which at best 200 MB is <br>
available after kernel has booted.<br>
<br>
I'm now a bit confused as to why fallocate05 test worked previously. <br>
With release 20210524 version, I see the following:<br></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">Ah, I see, that because we set the tmpfs size from the commit below,</div><div class="gmail_default" style="font-size:small">so you got 512MB tmpfs mount which is the root cause of OOM.</div><div class="gmail_default" style="font-size:small"><br></div>commit c305a53c561d8517340daa27790a3624f2491b72<br>Author: Li Wang <<a href="mailto:liwang@redhat.com">liwang@redhat.com</a>><br>Date:   Fri Jul 9 15:52:03 2021 +0800<br><br>    lib: limit the size of tmpfs in LTP<br>    <br>    LTP mount and make use of the whole tmpfs of the test system,<br>    generally, it's fine. But if a test (e.g fallocate06) try to<br>    fill full in the filesystem, it takes too long to complete<br>    testing on a large memory system.<br>    <br>    This patch adds a new function limit_tmpfs_mount_size with<br>    appending '-o size=xxM' to the mount options in prepare_device()<br>    which helps limit the tmpfs mount size.<br><div class="gmail_default" style="font-size:small"></div><div class="gmail_default" style="font-size:small">A simple way to verify my assumption, you can try:</div><div class="gmail_default" style="font-size:small"><br></div>--- a/testcases/kernel/syscalls/fallocate/fallocate05.c<br>+++ b/testcases/kernel/syscalls/fallocate/fallocate05.c<br>@@ -147,7 +147,7 @@ static void cleanup(void)<br> static struct tst_test test = {<br>        .needs_root = 1,<br>        .mount_device = 1,<br>-       .dev_min_size = 512,<br>+       .dev_min_size = 64,<br>        .mntpoint = MNTPOINT,<br>        .all_filesystems = 1,<br>        .setup = setup,<br><div class="gmail_default" style="font-size:small"></div></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>
tst_test.c:1379: TINFO: Testing on tmpfs<br>
tst_test.c:888: TINFO: Skipping mkfs for TMPFS filesystem<br>
tst_test.c:1311: TINFO: Timeout per run is 0h 15m 00s<br>
tst_fill_fs.c:32: TINFO: Creating file mntpoint/file0 size 21710183<br>
tst_fill_fs.c:32: TINFO: Creating file mntpoint/file1 size 8070086<br>
tst_fill_fs.c:32: TINFO: Creating file mntpoint/file2 size 3971177<br>
tst_fill_fs.c:32: TINFO: Creating file mntpoint/file3 size 36915315<br>
tst_fill_fs.c:32: TINFO: Creating file mntpoint/file4 size 70310993<br>
tst_fill_fs.c:59: TINFO: write(): ENOSPC (28)<br>
fallocate05.c:81: TPASS: write() wrote 65536 bytes<br>
fallocate05.c:102: TINFO: fallocate()d 0 extra blocks on full FS<br>
fallocate05.c:114: TPASS: fallocate() on full FS<br>
fallocate05.c:130: TPASS: fallocate(FALLOC_FL_PUNCH_HOLE | FALLOC_FL_KEEP_SIZE)<br>
fallocate05.c:136: TPASS: write()<br>
<br>
Whereas with the latest git version, it seems to create two more <br>
additional files, before OOM kicks in:<br></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">Before the above commit, LTP took the whole tmpfs of SUT,</div><div class="gmail_default" style="font-size:small">so the test size depends on the real system situation. </div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">We  do the improvement because we don't want to use larger</div><div class="gmail_default" style="font-size:small">tmpfs size on a Huge RAM machine. But seems we neglect small</div><div class="gmail_default" style="font-size:small">systems :).</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>
tst_test.c:1421: TINFO: Testing on tmpfs<br>
tst_test.c:922: TINFO: Skipping mkfs for TMPFS filesystem<br>
tst_test.c:903: TINFO: Limiting tmpfs size to 512MB<br>
tst_test.c:1353: TINFO: Timeout per run is 0h 15m 00s<br>
tst_fill_fs.c:32: TINFO: Creating file mntpoint/file0 size 21710183<br>
tst_fill_fs.c:32: TINFO: Creating file mntpoint/file1 size 8070086<br>
tst_fill_fs.c:32: TINFO: Creating file mntpoint/file2 size 3971177<br>
tst_fill_fs.c:32: TINFO: Creating file mntpoint/file3 size 36915315<br>
tst_fill_fs.c:32: TINFO: Creating file mntpoint/file4 size 70310993<br>
tst_fill_fs.c:32: TINFO: Creating file mntpoint/file5 size 4807935<br>
tst_fill_fs.c:32: TINFO: Creating file mntpoint/file6 size 90739786<br>
<... OOM begins here ...><br>
<br>
Any thoughts on what might be happening?<br>
<br>
Regards,<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>