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

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

[Li Wang]

The last write(fd, buf, 10) in the test is used to detect whether
'FALLOC_FL_PUNCH_HOLE | FALLOC_FL_KEEP_SIZE' deallocating file space
success or not.

But it is not to be a reliable way on returning ENOSPEC if the defallocated
space is too small(only 4 blocks, x86_64). That's because filesystem metadata
might be extending to occupy that space during punch a hole.

Better to increase the size of fallocate/defallocate to reduce interference
from metadata changing.

    33	tst_test.c:1410: TINFO: Testing on ext4
    34	tst_test.c:914: TINFO: Formatting /dev/loop0 with ext4 opts='' extra opts=''
    35	mke2fs 1.45.6 (20-Mar-2020)
    36	tst_test.c:1342: TINFO: Timeout per run is 0h 05m 00s
    37	tst_fill_fs.c:32: TINFO: Creating file mntpoint/file0 size 21710183
        ...
    46	tst_fill_fs.c:32: TINFO: Creating file mntpoint/file9 size 36207821
    47	tst_fill_fs.c:32: TINFO: Creating file mntpoint/file10 size 81483962
    48	tst_fill_fs.c:59: TINFO: write(): ENOSPC (28)
    49	fallocate05.c:81: TPASS: write() wrote 65536 bytes
    50	fallocate05.c:102: TINFO: fallocate()d 0 extra blocks on full FS
    51	fallocate05.c:114: TPASS: fallocate() on full FS
    52	fallocate05.c:130: TPASS: fallocate(FALLOC_FL_PUNCH_HOLE | FALLOC_FL_KEEP_SIZE)
    53	fallocate05.c:134: TFAIL: write(): ENOSPC (28)

Signed-off-by: Li Wang <liwang@redhat.com>
---
 testcases/kernel/syscalls/fallocate/fallocate05.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/testcases/kernel/syscalls/fallocate/fallocate05.c b/testcases/kernel/syscalls/fallocate/fallocate05.c
index 55ec1aee4..74bfa4861 100644
--- a/testcases/kernel/syscalls/fallocate/fallocate05.c
+++ b/testcases/kernel/syscalls/fallocate/fallocate05.c
@@ -26,8 +26,8 @@
 #include "lapi/fallocate.h"
 
 #define MNTPOINT "mntpoint"
-#define FALLOCATE_BLOCKS 16
-#define DEALLOCATE_BLOCKS 4
+#define FALLOCATE_BLOCKS 256
+#define DEALLOCATE_BLOCKS 64
 #define TESTED_FLAGS "fallocate(FALLOC_FL_PUNCH_HOLE | FALLOC_FL_KEEP_SIZE)"
 
 static char *buf;
-- 
2.31.1

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

[Li Wang]

[-- Attachment #1.1: Type: text/plain, Size: 217 bytes --]

Ping~

This patch is only to increase the test blocks to make it robust,
it's no harmful and actually changes nothing from code logic.

I will merge this if no objection by the end of this week.

-- 
Regards,
Li Wang

[-- Attachment #1.2: Type: text/html, Size: 721 bytes --]

[-- Attachment #2: Type: text/plain, Size: 60 bytes --]


-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

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

[Li Wang]

[-- Attachment #1.1: Type: text/plain, Size: 217 bytes --]

Ping~

This patch is only to increase the test blocks to make it robust,
it's no harmful and actually changes nothing from code logic.

I will merge this if no objection by the end of this week.

-- 
Regards,
Li Wang

[-- Attachment #1.2: Type: text/html, Size: 721 bytes --]

[-- Attachment #2: Type: text/plain, Size: 60 bytes --]


-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

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

[Jan Stancek]

[-- Attachment #1.1: Type: text/plain, Size: 256 bytes --]

On Tue, Sep 7, 2021 at 4:40 AM Li Wang <liwang@redhat.com> wrote:

> Ping~
>
> This patch is only to increase the test blocks to make it robust,
> it's no harmful and actually changes nothing from code logic.
>

Acked-by: Jan Stancek <jstancek@redhat.com>

[-- Attachment #1.2: Type: text/html, Size: 882 bytes --]

[-- Attachment #2: Type: text/plain, Size: 60 bytes --]


-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

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

[Jan Stancek]

[-- Attachment #1.1: Type: text/plain, Size: 256 bytes --]

On Tue, Sep 7, 2021 at 4:40 AM Li Wang <liwang@redhat.com> wrote:

> Ping~
>
> This patch is only to increase the test blocks to make it robust,
> it's no harmful and actually changes nothing from code logic.
>

Acked-by: Jan Stancek <jstancek@redhat.com>

[-- Attachment #1.2: Type: text/html, Size: 882 bytes --]

[-- Attachment #2: Type: text/plain, Size: 60 bytes --]


-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

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

[Li Wang]

[-- Attachment #1.1: Type: text/plain, Size: 393 bytes --]

On Tue, Sep 7, 2021 at 4:00 PM Jan Stancek <jstancek@redhat.com> wrote:

>
>
> On Tue, Sep 7, 2021 at 4:40 AM Li Wang <liwang@redhat.com> wrote:
>
>> Ping~
>>
>> This patch is only to increase the test blocks to make it robust,
>> it's no harmful and actually changes nothing from code logic.
>>
>
> Acked-by: Jan Stancek <jstancek@redhat.com>
>

Thanks for ACK, pushed.

-- 
Regards,
Li Wang

[-- Attachment #1.2: Type: text/html, Size: 1554 bytes --]

[-- Attachment #2: Type: text/plain, Size: 60 bytes --]


-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

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

[Li Wang]

[-- Attachment #1.1: Type: text/plain, Size: 393 bytes --]

On Tue, Sep 7, 2021 at 4:00 PM Jan Stancek <jstancek@redhat.com> wrote:

>
>
> On Tue, Sep 7, 2021 at 4:40 AM Li Wang <liwang@redhat.com> wrote:
>
>> Ping~
>>
>> This patch is only to increase the test blocks to make it robust,
>> it's no harmful and actually changes nothing from code logic.
>>
>
> Acked-by: Jan Stancek <jstancek@redhat.com>
>

Thanks for ACK, pushed.

-- 
Regards,
Li Wang

[-- Attachment #1.2: Type: text/html, Size: 1554 bytes --]

[-- Attachment #2: Type: text/plain, Size: 60 bytes --]


-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

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

[Ralph Siemsen]

Hello,

On Tue, Aug 17, 2021 at 06:46:25PM +0800, Li Wang wrote:
>
>diff --git a/testcases/kernel/syscalls/fallocate/fallocate05.c b/testcases/kernel/syscalls/fallocate/fallocate05.c
>index 55ec1aee4..74bfa4861 100644
>--- a/testcases/kernel/syscalls/fallocate/fallocate05.c
>+++ b/testcases/kernel/syscalls/fallocate/fallocate05.c
>@@ -26,8 +26,8 @@
> #include "lapi/fallocate.h"
>
> #define MNTPOINT "mntpoint"
>-#define FALLOCATE_BLOCKS 16
>-#define DEALLOCATE_BLOCKS 4
>+#define FALLOCATE_BLOCKS 256
>+#define DEALLOCATE_BLOCKS 64
> #define TESTED_FLAGS "fallocate(FALLOC_FL_PUNCH_HOLE | FALLOC_FL_KEEP_SIZE)"
>
> static char *buf;

This change appears seems to be causing fallocate05 test to reliably 
trigger OOM (out of memory) on my test machine, which has only 256MB 
RAM.

I previously used the 20210524 and 20200120 release versions, and did 
not encounter this problem.

Regards,
Ralph

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

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

[Li Wang]

[-- Attachment #1.1: Type: text/plain, Size: 1318 bytes --]

Hi Ralph,

On Wed, Sep 22, 2021 at 4:34 AM Ralph Siemsen <ralph.siemsen@linaro.org>
wrote:

> Hello,
>
> On Tue, Aug 17, 2021 at 06:46:25PM +0800, Li Wang wrote:
> >
> >diff --git a/testcases/kernel/syscalls/fallocate/fallocate05.c
> b/testcases/kernel/syscalls/fallocate/fallocate05.c
> >index 55ec1aee4..74bfa4861 100644
> >--- a/testcases/kernel/syscalls/fallocate/fallocate05.c
> >+++ b/testcases/kernel/syscalls/fallocate/fallocate05.c
> >@@ -26,8 +26,8 @@
> > #include "lapi/fallocate.h"
> >
> > #define MNTPOINT "mntpoint"
> >-#define FALLOCATE_BLOCKS 16
> >-#define DEALLOCATE_BLOCKS 4
> >+#define FALLOCATE_BLOCKS 256
> >+#define DEALLOCATE_BLOCKS 64
> > #define TESTED_FLAGS "fallocate(FALLOC_FL_PUNCH_HOLE |
> FALLOC_FL_KEEP_SIZE)"
> >
> > static char *buf;
>
> This change appears seems to be causing fallocate05 test to reliably
> trigger OOM (out of memory) on my test machine, which has only 256MB
> RAM.
>

Thanks for reporting the failure. We purposely increase the size of
fallocate
to reduce interference from metadata changing. But not clear how much
size should be a proper value for a small system.

Can you try with decrease the number of FALLOCATE_BLOCKS?

i.e.

#define FALLOCATE_BLOCKS 64
#define DEALLOCATE_BLOCKS 16

Or, what about other multiple sizes, test result?


-- 
Regards,
Li Wang

[-- Attachment #1.2: Type: text/html, Size: 2808 bytes --]

[-- Attachment #2: Type: text/plain, Size: 60 bytes --]


-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

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

[Cyril Hrubis]

Hi!
> > This change appears seems to be causing fallocate05 test to reliably
> > trigger OOM (out of memory) on my test machine, which has only 256MB
> > RAM.
> >
> 
> Thanks for reporting the failure. We purposely increase the size of
> fallocate
> to reduce interference from metadata changing. But not clear how much
> size should be a proper value for a small system.
> 
> Can you try with decrease the number of FALLOCATE_BLOCKS?
> 
> i.e.
> 
> #define FALLOCATE_BLOCKS 64
> #define DEALLOCATE_BLOCKS 16
> 
> Or, what about other multiple sizes, test result?

Looking at the test I do not think there is a reason to allocate more
than a two or four blocks for the buffer. We just need to write() to the
fallocated area in a loop one block at a time until it's full. I do not
think that it's a good idea to pass ~100MB buffer to a single write()
and expect it to succeed anyways.

-- 
Cyril Hrubis
chrubis@suse.cz

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

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

[Li Wang]

[-- Attachment #1.1: Type: text/plain, Size: 1227 bytes --]

On Wed, Sep 22, 2021 at 4:21 PM Cyril Hrubis <chrubis@suse.cz> wrote:

> Hi!
> > > This change appears seems to be causing fallocate05 test to reliably
> > > trigger OOM (out of memory) on my test machine, which has only 256MB
> > > RAM.
> > >
> >
> > Thanks for reporting the failure. We purposely increase the size of
> > fallocate
> > to reduce interference from metadata changing. But not clear how much
> > size should be a proper value for a small system.
> >
> > Can you try with decrease the number of FALLOCATE_BLOCKS?
> >
> > i.e.
> >
> > #define FALLOCATE_BLOCKS 64
> > #define DEALLOCATE_BLOCKS 16
> >
> > Or, what about other multiple sizes, test result?
>
> Looking at the test I do not think there is a reason to allocate more
> than a two or four blocks for the buffer. We just need to write() to the
> fallocated area in a loop one block at a time until it's full. I do not
> think that it's a good idea to pass ~100MB buffer to a single write()
> and expect it to succeed anyways.
>

Sounds practical.

Btw, If we don't create such a larger buffer area, then we have to
count the loop times must as equal to bufsize/blocksize. Otherwise,
we can't guarantee the test behavior is correct.

-- 
Regards,
Li Wang

[-- Attachment #1.2: Type: text/html, Size: 2113 bytes --]

[-- Attachment #2: Type: text/plain, Size: 60 bytes --]


-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

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

[Cyril Hrubis]

Hi!
> > Looking at the test I do not think there is a reason to allocate more
> > than a two or four blocks for the buffer. We just need to write() to the
> > fallocated area in a loop one block at a time until it's full. I do not
> > think that it's a good idea to pass ~100MB buffer to a single write()
> > and expect it to succeed anyways.
> >
> 
> Sounds practical.
> 
> Btw, If we don't create such a larger buffer area, then we have to
> count the loop times must as equal to bufsize/blocksize. Otherwise,
> we can't guarantee the test behavior is correct.

Strangely enough we allready do exactly that for the second part of the test.

-- 
Cyril Hrubis
chrubis@suse.cz

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

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

[Li Wang]

[-- Attachment #1.1: Type: text/plain, Size: 987 bytes --]

On Wed, Sep 22, 2021 at 5:56 PM Cyril Hrubis <chrubis@suse.cz> wrote:

> Hi!
> > > Looking at the test I do not think there is a reason to allocate more
> > > than a two or four blocks for the buffer. We just need to write() to
> the
> > > fallocated area in a loop one block at a time until it's full. I do not
> > > think that it's a good idea to pass ~100MB buffer to a single write()
> > > and expect it to succeed anyways.
> > >
> >
> > Sounds practical.
> >
> > Btw, If we don't create such a larger buffer area, then we have to
> > count the loop times must as equal to bufsize/blocksize. Otherwise,
> > we can't guarantee the test behavior is correct.
>
> Strangely enough we allready do exactly that for the second part of the
> test.
>

That try one by one block after filling full of the FS because nobody knows
when fails.

But as you suggested we can do that as well for the previous allocation :).

So, will you create a patch, or I do that tomorrow?

-- 
Regards,
Li Wang

[-- Attachment #1.2: Type: text/html, Size: 1872 bytes --]

[-- Attachment #2: Type: text/plain, Size: 60 bytes --]


-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

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

[Cyril Hrubis]

Hi!
> > > Sounds practical.
> > >
> > > Btw, If we don't create such a larger buffer area, then we have to
> > > count the loop times must as equal to bufsize/blocksize. Otherwise,
> > > we can't guarantee the test behavior is correct.
> >
> > Strangely enough we allready do exactly that for the second part of the
> > test.
> >
> 
> That try one by one block after filling full of the FS because nobody knows
> when fails.
> 
> But as you suggested we can do that as well for the previous allocation :).
> 
> So, will you create a patch, or I do that tomorrow?

I will not manage today. So either you do it or I can do it tomorrow
:-).

-- 
Cyril Hrubis
chrubis@suse.cz

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

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

[Ralph Siemsen]

Hello,

On Wed, Sep 22, 2021 at 04:32:45PM +0200, Cyril Hrubis wrote:
>>
>> That try one by one block after filling full of the FS because nobody knows
>> when fails.
>>
>> But as you suggested we can do that as well for the previous allocation :).
>>
>> So, will you create a patch, or I do that tomorrow?
>
>I will not manage today. So either you do it or I can do it tomorrow
>:-).

I tried making a patch for this, which I can share. But after testing, I 
am still seeing OOM. Upon further inspection, it seems to be coming from 
tst_fill_fs() function, when operating on a tmpfs.  I see the message:

tst_test.c:903: TINFO: Limiting tmpfs size to 512MB

However the machine only has 256MB total, of which at best 200 MB is 
available after kernel has booted.

I'm now a bit confused as to why fallocate05 test worked previously. 
With release 20210524 version, I see the following:

tst_test.c:1379: TINFO: Testing on tmpfs
tst_test.c:888: TINFO: Skipping mkfs for TMPFS filesystem
tst_test.c:1311: TINFO: Timeout per run is 0h 15m 00s
tst_fill_fs.c:32: TINFO: Creating file mntpoint/file0 size 21710183
tst_fill_fs.c:32: TINFO: Creating file mntpoint/file1 size 8070086
tst_fill_fs.c:32: TINFO: Creating file mntpoint/file2 size 3971177
tst_fill_fs.c:32: TINFO: Creating file mntpoint/file3 size 36915315
tst_fill_fs.c:32: TINFO: Creating file mntpoint/file4 size 70310993
tst_fill_fs.c:59: TINFO: write(): ENOSPC (28)
fallocate05.c:81: TPASS: write() wrote 65536 bytes
fallocate05.c:102: TINFO: fallocate()d 0 extra blocks on full FS
fallocate05.c:114: TPASS: fallocate() on full FS
fallocate05.c:130: TPASS: fallocate(FALLOC_FL_PUNCH_HOLE | FALLOC_FL_KEEP_SIZE)
fallocate05.c:136: TPASS: write()

Whereas with the latest git version, it seems to create two more 
additional files, before OOM kicks in:

tst_test.c:1421: TINFO: Testing on tmpfs
tst_test.c:922: TINFO: Skipping mkfs for TMPFS filesystem
tst_test.c:903: TINFO: Limiting tmpfs size to 512MB
tst_test.c:1353: TINFO: Timeout per run is 0h 15m 00s
tst_fill_fs.c:32: TINFO: Creating file mntpoint/file0 size 21710183
tst_fill_fs.c:32: TINFO: Creating file mntpoint/file1 size 8070086
tst_fill_fs.c:32: TINFO: Creating file mntpoint/file2 size 3971177
tst_fill_fs.c:32: TINFO: Creating file mntpoint/file3 size 36915315
tst_fill_fs.c:32: TINFO: Creating file mntpoint/file4 size 70310993
tst_fill_fs.c:32: TINFO: Creating file mntpoint/file5 size 4807935
tst_fill_fs.c:32: TINFO: Creating file mntpoint/file6 size 90739786
<... OOM begins here ...>

Any thoughts on what might be happening?

Regards,
Ralph

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

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

[Li Wang]

[-- Attachment #1.1: Type: text/plain, Size: 4191 bytes --]

On Thu, Sep 23, 2021 at 12:52 AM Ralph Siemsen <ralph.siemsen@linaro.org>
wrote:

> Hello,
>
> On Wed, Sep 22, 2021 at 04:32:45PM +0200, Cyril Hrubis wrote:
> >>
> >> That try one by one block after filling full of the FS because nobody
> knows
> >> when fails.
> >>
> >> But as you suggested we can do that as well for the previous allocation
> :).
> >>
> >> So, will you create a patch, or I do that tomorrow?
> >
> >I will not manage today. So either you do it or I can do it tomorrow
> >:-).
>
> I tried making a patch for this, which I can share. But after testing, I
> am still seeing OOM. Upon further inspection, it seems to be coming from
> tst_fill_fs() function, when operating on a tmpfs.  I see the message:
>
> tst_test.c:903: TINFO: Limiting tmpfs size to 512MB
>
> However the machine only has 256MB total, of which at best 200 MB is
> available after kernel has booted.
>
> I'm now a bit confused as to why fallocate05 test worked previously.
> With release 20210524 version, I see the following:
>

Ah, I see, that because we set the tmpfs size from the commit below,
so you got 512MB tmpfs mount which is the root cause of OOM.

commit c305a53c561d8517340daa27790a3624f2491b72
Author: Li Wang <liwang@redhat.com>
Date:   Fri Jul 9 15:52:03 2021 +0800

    lib: limit the size of tmpfs in LTP

    LTP mount and make use of the whole tmpfs of the test system,
    generally, it's fine. But if a test (e.g fallocate06) try to
    fill full in the filesystem, it takes too long to complete
    testing on a large memory system.

    This patch adds a new function limit_tmpfs_mount_size with
    appending '-o size=xxM' to the mount options in prepare_device()
    which helps limit the tmpfs mount size.
A simple way to verify my assumption, you can try:

--- a/testcases/kernel/syscalls/fallocate/fallocate05.c
+++ b/testcases/kernel/syscalls/fallocate/fallocate05.c
@@ -147,7 +147,7 @@ static void cleanup(void)
 static struct tst_test test = {
        .needs_root = 1,
        .mount_device = 1,
-       .dev_min_size = 512,
+       .dev_min_size = 64,
        .mntpoint = MNTPOINT,
        .all_filesystems = 1,
        .setup = setup,


>
> tst_test.c:1379: TINFO: Testing on tmpfs
> tst_test.c:888: TINFO: Skipping mkfs for TMPFS filesystem
> tst_test.c:1311: TINFO: Timeout per run is 0h 15m 00s
> tst_fill_fs.c:32: TINFO: Creating file mntpoint/file0 size 21710183
> tst_fill_fs.c:32: TINFO: Creating file mntpoint/file1 size 8070086
> tst_fill_fs.c:32: TINFO: Creating file mntpoint/file2 size 3971177
> tst_fill_fs.c:32: TINFO: Creating file mntpoint/file3 size 36915315
> tst_fill_fs.c:32: TINFO: Creating file mntpoint/file4 size 70310993
> tst_fill_fs.c:59: TINFO: write(): ENOSPC (28)
> fallocate05.c:81: TPASS: write() wrote 65536 bytes
> fallocate05.c:102: TINFO: fallocate()d 0 extra blocks on full FS
> fallocate05.c:114: TPASS: fallocate() on full FS
> fallocate05.c:130: TPASS: fallocate(FALLOC_FL_PUNCH_HOLE |
> FALLOC_FL_KEEP_SIZE)
> fallocate05.c:136: TPASS: write()
>
> Whereas with the latest git version, it seems to create two more
> additional files, before OOM kicks in:
>

Before the above commit, LTP took the whole tmpfs of SUT,
so the test size depends on the real system situation.

We  do the improvement because we don't want to use larger
tmpfs size on a Huge RAM machine. But seems we neglect small
systems :).



>
> tst_test.c:1421: TINFO: Testing on tmpfs
> tst_test.c:922: TINFO: Skipping mkfs for TMPFS filesystem
> tst_test.c:903: TINFO: Limiting tmpfs size to 512MB
> tst_test.c:1353: TINFO: Timeout per run is 0h 15m 00s
> tst_fill_fs.c:32: TINFO: Creating file mntpoint/file0 size 21710183
> tst_fill_fs.c:32: TINFO: Creating file mntpoint/file1 size 8070086
> tst_fill_fs.c:32: TINFO: Creating file mntpoint/file2 size 3971177
> tst_fill_fs.c:32: TINFO: Creating file mntpoint/file3 size 36915315
> tst_fill_fs.c:32: TINFO: Creating file mntpoint/file4 size 70310993
> tst_fill_fs.c:32: TINFO: Creating file mntpoint/file5 size 4807935
> tst_fill_fs.c:32: TINFO: Creating file mntpoint/file6 size 90739786
> <... OOM begins here ...>
>
> Any thoughts on what might be happening?
>
> Regards,
> Ralph
>
>

-- 
Regards,
Li Wang

[-- Attachment #1.2: Type: text/html, Size: 6223 bytes --]

[-- Attachment #2: Type: text/plain, Size: 60 bytes --]


-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

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

[Li Wang]

[-- Attachment #1.1: Type: text/plain, Size: 1109 bytes --]

> A simple way to verify my assumption, you can try:
>
> --- a/testcases/kernel/syscalls/fallocate/fallocate05.c
> +++ b/testcases/kernel/syscalls/fallocate/fallocate05.c
> @@ -147,7 +147,7 @@ static void cleanup(void)
>  static struct tst_test test = {
>         .needs_root = 1,
>         .mount_device = 1,
> -       .dev_min_size = 512,
> +       .dev_min_size = 64,
>         .mntpoint = MNTPOINT,
>         .all_filesystems = 1,
>         .setup = setup,
>


Or, another way I can think of, is to cancel the tmpfs size limitation
when MemFree is less than the twofold size to be mounted.

(I guess guarantee twofold size MemFree is safe enough for avoiding OOM)


--- a/lib/tst_test.c
+++ b/lib/tst_test.c
@@ -895,6 +895,9 @@ static const char *limit_tmpfs_mount_size(const char
*mnt_data,
        if (strcmp(fs_type, "tmpfs"))
                return mnt_data;

+       if ((SAFE_READ_MEMINFO("MemFree:") / 1024) < (tdev.size * 2))
+               return mnt_data;
+
        if (mnt_data)
                snprintf(buf, buf_size, "%s,size=%luM", mnt_data,
tdev.size);
        else


-- 
Regards,
Li Wang

[-- Attachment #1.2: Type: text/html, Size: 2237 bytes --]

[-- Attachment #2: Type: text/plain, Size: 60 bytes --]


-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

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

[Cyril Hrubis]

Hi!
> Or, another way I can think of, is to cancel the tmpfs size limitation
> when MemFree is less than the twofold size to be mounted.

This would fail horribly if the machine has all RAM used but there is
plenty in buffers that should be freed.

I guess that we should really add tst_available_ram() function that
would print either MemAvailable or sum of MemFree + MemCached. And of
course we shouldn't eat more than half of that in the tests.

> --- a/lib/tst_test.c
> +++ b/lib/tst_test.c
> @@ -895,6 +895,9 @@ static const char *limit_tmpfs_mount_size(const char
> *mnt_data,
>         if (strcmp(fs_type, "tmpfs"))
>                 return mnt_data;
> 
> +       if ((SAFE_READ_MEMINFO("MemFree:") / 1024) < (tdev.size * 2))
> +               return mnt_data;

I guess that we should as well skip the tmpfs completely if we think
that the size is too small as well.

>         if (mnt_data)
>                 snprintf(buf, buf_size, "%s,size=%luM", mnt_data,
> tdev.size);
>         else
> 
> 
> -- 
> Regards,
> Li Wang

-- 
Cyril Hrubis
chrubis@suse.cz

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

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

[Li Wang]

[-- Attachment #1.1: Type: text/plain, Size: 1211 bytes --]

On Thu, Sep 23, 2021 at 9:09 PM Cyril Hrubis <chrubis@suse.cz> wrote:

> Hi!
> > Or, another way I can think of, is to cancel the tmpfs size limitation
> > when MemFree is less than the twofold size to be mounted.
>
> This would fail horribly if the machine has all RAM used but there is
> plenty in buffers that should be freed.
>
> I guess that we should really add tst_available_ram() function that
> would print either MemAvailable or sum of MemFree + MemCached. And of
> course we shouldn't eat more than half of that in the tests.
>

Agreed. I would like to put into tst_memutils.h.



>
> > --- a/lib/tst_test.c
> > +++ b/lib/tst_test.c
> > @@ -895,6 +895,9 @@ static const char *limit_tmpfs_mount_size(const char
> > *mnt_data,
> >         if (strcmp(fs_type, "tmpfs"))
> >                 return mnt_data;
> >
> > +       if ((SAFE_READ_MEMINFO("MemFree:") / 1024) < (tdev.size * 2))
> > +               return mnt_data;
>
> I guess that we should as well skip the tmpfs completely if we think
> that the size is too small as well.
>

Just canceling the tmpfs size should work so far, since Ralph said
he got PASS on 20210524-version, which does not include the size
limitation.


-- 
Regards,
Li Wang

[-- Attachment #1.2: Type: text/html, Size: 2275 bytes --]

[-- Attachment #2: Type: text/plain, Size: 60 bytes --]


-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

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

[Cyril Hrubis]

Hi!
FYI I've tried to run syscalls on a VM with 256MB RAM just to see what
explodes and it looks like futex_cmp_requeue01 fails as well because we
don't have enough memory to fork 1000 processes. I guess that we really
need an API for at least rough scaling for the number of processes we
can run based on free memory. With that we could finally fix the
msgstress testcases as well.

Also it seems that in my case the tmpfs returns ENOSPC correctly when
the machine free memory gets low enough regardless of the limit set at
the mount time, and that's 4.19.0-16-amd64. So I guess that there may be
something wrong in the kernel you are testing after all.

-- 
Cyril Hrubis
chrubis@suse.cz

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

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

[Ralph Siemsen]

Thanks for the suggestions!

I have tried setting .dev_min_size = 64, in addition to setting 
FALLOCATE_BLOCKS back to the previous value of 16. Unfortunately I am 
still seeing OOM when filling the tmpfs. I am confident I made the 
change correctly, as I can see the message:

tst_test.c:903: TINFO: Limiting tmpfs size to 64MB

For other filesystems (ext4/btrfs/vfat) the test is fine, and I get 
ENOSPC error as expected.

I'm testing on kernel version 5.10.52 currently, but I could also switch 
back to 4.19. I'm on ARMv7 rather than amd64.

Regards,
Ralph

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

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

[Li Wang]

[-- Attachment #1.1: Type: text/plain, Size: 1017 bytes --]

On Fri, Sep 24, 2021 at 9:49 AM Ralph Siemsen <ralph.siemsen@linaro.org>
wrote:

> Thanks for the suggestions!
>
> I have tried setting .dev_min_size = 64, in addition to setting
> FALLOCATE_BLOCKS back to the previous value of 16. Unfortunately I am
> still seeing OOM when filling the tmpfs. I am confident I made the
> change correctly, as I can see the message:
>

That's weird.

What about the testing result with unlimit the tmpfs size?

My second thoughts mentioned above (if it works, I will
fix it by following Cyril's suggestion).



> tst_test.c:903: TINFO: Limiting tmpfs size to 64MB
>

Hmm, set to 16MB, 32MB? test result?

Can you post the /proc/meminfo here? I'm curious how
small memory it is can not tolerate 64M consuming.



>
> For other filesystems (ext4/btrfs/vfat) the test is fine, and I get
> ENOSPC error as expected.
>
> I'm testing on kernel version 5.10.52 currently, but I could also switch
> back to 4.19. I'm on ARMv7 rather than amd64.
>
> Regards,
> Ralph
>
>

-- 
Regards,
Li Wang

[-- Attachment #1.2: Type: text/html, Size: 2541 bytes --]

[-- Attachment #2: Type: text/plain, Size: 60 bytes --]


-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

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

[Ralph Siemsen]

On Fri, Sep 24, 2021 at 12:18:45PM +0800, Li Wang wrote:
>
>That's weird.
>
>What about the testing result with unlimit the tmpfs size?

With the .dev_min_size field set to zero, it still causes OOM. Looking 
at the test output, it seems to use 256MB in this case:

tst_test.c:1421: TINFO: Testing on tmpfs
tst_test.c:922: TINFO: Skipping mkfs for TMPFS filesystem
tst_test.c:903: TINFO: Limiting tmpfs size to 256MB
tst_test.c:1353: TINFO: Timeout per run is 0h 15m 00s
tst_fill_fs.c:32: TINFO: Creating file mntpoint/file0 size 21710183
tst_fill_fs.c:32: TINFO: Creating file mntpoint/file1 size 8070086
tst_fill_fs.c:32: TINFO: Creating file mntpoint/file2 size 3971177
tst_fill_fs.c:32: TINFO: Creating file mntpoint/file3 size 36915315
tst_fill_fs.c:32: TINFO: Creating file mntpoint/file4 size 70310993
tst_fill_fs.c:32: TINFO: Creating file mntpoint/file5 size 4807935
tst_fill_fs.c:32: TINFO: Creating file mntpoint/file6 size 90739786
tcf-agent invoked oom-killer: gfp_mask=0x100cca(GFP_HIGHUSER_MOVABLE), order=0, oom_score_adj=0
[...]
Mem-Info:
active_anon:229 inactive_anon:44809 isolated_anon:0
  active_file:7 inactive_file:4 isolated_file:0
  unevictable:0 dirty:0 writeback:0
  slab_reclaimable:1205 slab_unreclaimable:3757
  mapped:334 shmem:42064 pagetables:226 bounce:0
  free:1004 free_pcp:0 free_cma:0
Node 0 active_anon:916kB inactive_anon:179236kB active_file:28kB inactive_file:88kB unevictable:0kB isolated(anon):0kB isolated(file) :0kB mapped:1336kB dirty:0kB writeback:0kB shmem:168256kB writeback_tmp:0kB kernel_stack:1016kB all_unreclaimable? no
Normal free:3776kB min:1872kB low:2340kB high:2808kB 
reserved_highatomic:0KB active_anon:916kB inactive_anon:179236kB active_file:28k B inactive_file:16kB unevictable:0kB writepending:0kB present:262144kB managed:220688kB mlocked:0kB pagetables:904kB bounce:0kB free_pcp:224kB local_pcp:0kB free_cma:0kB
lowmem_reserve[]: 0 0 0
Normal: 1*4kB (M) 1*8kB (M) 22*16kB (U) 35*32kB (UE) 16*64kB (UE) 9*128kB (UE) 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB 0*8192kB 0* 16384kB = 3660kB
42138 total pagecache pages

>> tst_test.c:903: TINFO: Limiting tmpfs size to 64MB
>
>Hmm, set to 16MB, 32MB? test result?

It does not reach the tmpfs test, because btrfs is unhappy:

tst_test.c:922: TINFO: Formatting /dev/loop0 with btrfs opts='' extra opts=''
ERROR: '/dev/loop0' is too small to make a usable filesystem
ERROR: minimum size for each btrfs device is 47185920
tst_test.c:922: TBROK: mkfs.btrfs failed with exit code 1

With a size of 48MB, machine still crashes with OOM.

>Can you post the /proc/meminfo here? I'm curious how
>small memory it is can not tolerate 64M consuming.

Here is what I get right after booting up, before starting ltp.sh tests. 
I've already disabled numerous services (nginx, redis, etc) to try and 
free up more memory.

MemTotal:         220688 kB
MemFree:          121064 kB
MemAvailable:     157484 kB
Buffers:            9376 kB
Cached:            38052 kB
SwapCached:            0 kB
Active:            16320 kB
Inactive:          45176 kB
Active(anon):        844 kB
Inactive(anon):    22492 kB
Active(file):      15476 kB
Inactive(file):    22684 kB
Unevictable:           0 kB
Mlocked:               0 kB
HighTotal:             0 kB
HighFree:              0 kB
LowTotal:         220688 kB
LowFree:          121064 kB
SwapTotal:             0 kB
SwapFree:              0 kB
Dirty:                60 kB
Writeback:             0 kB
AnonPages:         14140 kB
Mapped:            19244 kB
Shmem:              9268 kB
KReclaimable:       6260 kB
Slab:              20816 kB
SReclaimable:       6260 kB
SUnreclaim:        14556 kB
KernelStack:        1008 kB
PageTables:         1160 kB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:      110344 kB
Committed_AS:      93916 kB
VmallocTotal:    1818624 kB
VmallocUsed:        2308 kB
VmallocChunk:          0 kB
Percpu:              496 kB

Regards,
Ralph

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

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

[Cyril Hrubis]

Hi!
> >That's weird.
> >
> >What about the testing result with unlimit the tmpfs size?
> 
> With the .dev_min_size field set to zero, it still causes OOM. Looking 
> at the test output, it seems to use 256MB in this case:
> 
> tst_test.c:1421: TINFO: Testing on tmpfs
> tst_test.c:922: TINFO: Skipping mkfs for TMPFS filesystem
> tst_test.c:903: TINFO: Limiting tmpfs size to 256MB
> tst_test.c:1353: TINFO: Timeout per run is 0h 15m 00s
> tst_fill_fs.c:32: TINFO: Creating file mntpoint/file0 size 21710183
> tst_fill_fs.c:32: TINFO: Creating file mntpoint/file1 size 8070086
> tst_fill_fs.c:32: TINFO: Creating file mntpoint/file2 size 3971177
> tst_fill_fs.c:32: TINFO: Creating file mntpoint/file3 size 36915315
> tst_fill_fs.c:32: TINFO: Creating file mntpoint/file4 size 70310993
> tst_fill_fs.c:32: TINFO: Creating file mntpoint/file5 size 4807935
> tst_fill_fs.c:32: TINFO: Creating file mntpoint/file6 size 90739786
> tcf-agent invoked oom-killer: gfp_mask=0x100cca(GFP_HIGHUSER_MOVABLE), order=0, oom_score_adj=0
> [...]
> Mem-Info:
> active_anon:229 inactive_anon:44809 isolated_anon:0
>   active_file:7 inactive_file:4 isolated_file:0
>   unevictable:0 dirty:0 writeback:0
>   slab_reclaimable:1205 slab_unreclaimable:3757
>   mapped:334 shmem:42064 pagetables:226 bounce:0
>   free:1004 free_pcp:0 free_cma:0
> Node 0 active_anon:916kB inactive_anon:179236kB active_file:28kB inactive_file:88kB unevictable:0kB isolated(anon):0kB isolated(file) :0kB mapped:1336kB dirty:0kB writeback:0kB shmem:168256kB writeback_tmp:0kB kernel_stack:1016kB all_unreclaimable? no
> Normal free:3776kB min:1872kB low:2340kB high:2808kB 
> reserved_highatomic:0KB active_anon:916kB inactive_anon:179236kB active_file:28k B inactive_file:16kB unevictable:0kB writepending:0kB present:262144kB managed:220688kB mlocked:0kB pagetables:904kB bounce:0kB free_pcp:224kB local_pcp:0kB free_cma:0kB
> lowmem_reserve[]: 0 0 0
> Normal: 1*4kB (M) 1*8kB (M) 22*16kB (U) 35*32kB (UE) 16*64kB (UE) 9*128kB (UE) 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB 0*8192kB 0* 16384kB = 3660kB
> 42138 total pagecache pages

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

> >> tst_test.c:903: TINFO: Limiting tmpfs size to 64MB
> >
> >Hmm, set to 16MB, 32MB? test result?
> 
> It does not reach the tmpfs test, because btrfs is unhappy:
> 
> tst_test.c:922: TINFO: Formatting /dev/loop0 with btrfs opts='' extra opts=''
> ERROR: '/dev/loop0' is too small to make a usable filesystem
> ERROR: minimum size for each btrfs device is 47185920
> tst_test.c:922: TBROK: mkfs.btrfs failed with exit code 1
> 
> With a size of 48MB, machine still crashes with OOM.

Uff that really sounds like something is wrong with tmpfs implementation
in your kernel.

Meanwhile Li posted another patchset that adds limits for tmpfs
filesystem only and limits it to 32MB. Can you please test that one?
Also if that one fails as well it's likely that something is wrong at
your side.

-- 
Cyril Hrubis
chrubis@suse.cz

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

Re: [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

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

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

[Ralph Siemsen]

On Fri, Sep 24, 2021 at 04:26:01PM -0400, Ralph Siemsen wrote:

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

I am able to reproduce the behaviour under qemu ARM emulation. The 
kernel in this case is 5.4.142 -- a vanilla version directly from the 
stable 5.4.y kernel series.

I repeated tests 1) and 2) in this environment, getting essentially the 
same result as on the actual hardware:

1) LTP 20210524, fallocate05 test passes.

2) Latest git 443cbc1039f, fallocate05 seems to trigger OOM while
    filling up the tmpfs. Here is the complete log:
    https://gist.github.com/rfs613/f58bd803d1119bf30eb723aef4abf1f5
    The tmpfs test begins on line 759

It's getting late so I won't try the other tests right now, but can do 
so later if desired.

Regards,
Ralph

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

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

[Li Wang]

[-- Attachment #1.1: Type: text/plain, Size: 2432 bytes --]

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

[-- Attachment #1.2: Type: text/html, Size: 3784 bytes --]

[-- Attachment #2: Type: text/plain, Size: 60 bytes --]


-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

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

[Li Wang]

[-- Attachment #1.1: Type: text/plain, Size: 1379 bytes --]

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

FYI, for quick test and show tmpfs mount info, you could add debug code:

--- a/testcases/kernel/syscalls/fallocate/fallocate05.c
+++ b/testcases/kernel/syscalls/fallocate/fallocate05.c
@@ -50,6 +50,8 @@ static void setup(void)
        bufsize = FALLOCATE_BLOCKS * blocksize;
        buf = SAFE_MALLOC(bufsize);
        SAFE_CLOSE(fd);
+
+       tst_system("mount | column -t |grep tmpfs");
 }

 static void run(void)
@@ -153,4 +155,14 @@ static struct tst_test test = {
        .setup = setup,
        .cleanup = cleanup,
        .test_all = run,
+       .skip_filesystems = (const char *const []) {
+               "ext2",
+               "ext3",
+               "ext4",
+               "nfs",
+               "xfs",
+               "ntfs",
+               "btrfs",
+               NULL
+       },
 };


-- 
Regards,
Li Wang

[-- Attachment #1.2: Type: text/html, Size: 2685 bytes --]

[-- Attachment #2: Type: text/plain, Size: 60 bytes --]


-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

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

[Li Wang]

[-- Attachment #1.1: Type: text/plain, Size: 3094 bytes --]

On Sat, Sep 25, 2021 at 2:25 AM Cyril Hrubis <chrubis@suse.cz> wrote:

> Hi!
> > >That's weird.
> > >
> > >What about the testing result with unlimit the tmpfs size?
> >
> > With the .dev_min_size field set to zero, it still causes OOM. Looking
> > at the test output, it seems to use 256MB in this case:
>

With .dev_min_size==0 the test lib will choose default size 256MB for
instead.

However, unlimit tmpfs-size does not mean set .dev_min_size to zero.
It should be returned mnt_data directly in limit_tmpfs_mount_size.
That also does the 20210524 version.

e.g.

--- a/lib/tst_test.c
+++ b/lib/tst_test.c
@@ -892,6 +892,8 @@ static void prepare_and_mount_dev_fs(const char
*mntpoint)
 static const char *limit_tmpfs_mount_size(const char *mnt_data,
                char *buf, size_t buf_size, const char *fs_type)
 {
+       return mnt_data;
+
        if (strcmp(fs_type, "tmpfs"))
                return mnt_data;



> >
> > tst_test.c:1421: TINFO: Testing on tmpfs
> > tst_test.c:922: TINFO: Skipping mkfs for TMPFS filesystem
> > tst_test.c:903: TINFO: Limiting tmpfs size to 256MB
> > tst_test.c:1353: TINFO: Timeout per run is 0h 15m 00s
> > tst_fill_fs.c:32: TINFO: Creating file mntpoint/file0 size 21710183
> > tst_fill_fs.c:32: TINFO: Creating file mntpoint/file1 size 8070086
> > tst_fill_fs.c:32: TINFO: Creating file mntpoint/file2 size 3971177
> > tst_fill_fs.c:32: TINFO: Creating file mntpoint/file3 size 36915315
> > tst_fill_fs.c:32: TINFO: Creating file mntpoint/file4 size 70310993
> > tst_fill_fs.c:32: TINFO: Creating file mntpoint/file5 size 4807935
> > tst_fill_fs.c:32: TINFO: Creating file mntpoint/file6 size 90739786
> > tcf-agent invoked oom-killer: gfp_mask=0x100cca(GFP_HIGHUSER_MOVABLE),
> order=0, oom_score_adj=0
> > [...]
> > Mem-Info:
> > active_anon:229 inactive_anon:44809 isolated_anon:0
> >   active_file:7 inactive_file:4 isolated_file:0
> >   unevictable:0 dirty:0 writeback:0
> >   slab_reclaimable:1205 slab_unreclaimable:3757
> >   mapped:334 shmem:42064 pagetables:226 bounce:0
> >   free:1004 free_pcp:0 free_cma:0
> > Node 0 active_anon:916kB inactive_anon:179236kB active_file:28kB
> inactive_file:88kB unevictable:0kB isolated(anon):0kB isolated(file) :0kB
> mapped:1336kB dirty:0kB writeback:0kB shmem:168256kB writeback_tmp:0kB
> kernel_stack:1016kB all_unreclaimable? no
> > Normal free:3776kB min:1872kB low:2340kB high:2808kB
> > reserved_highatomic:0KB active_anon:916kB inactive_anon:179236kB
> active_file:28k B inactive_file:16kB unevictable:0kB writepending:0kB
> present:262144kB managed:220688kB mlocked:0kB pagetables:904kB bounce:0kB
> free_pcp:224kB local_pcp:0kB free_cma:0kB
> > lowmem_reserve[]: 0 0 0
> > Normal: 1*4kB (M) 1*8kB (M) 22*16kB (U) 35*32kB (UE) 16*64kB (UE)
> 9*128kB (UE) 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB 0*8192kB 0* 16384kB
> = 3660kB
> > 42138 total pagecache pages
>
> That is strange, for me the tmpfs starts to return ENOSPC when the
> system is getting low on memory.
>

Maybe he enabled some OOM kernel options you didn't.
Or, some other configuration we don't know.


-- 
Regards,
Li Wang

[-- Attachment #1.2: Type: text/html, Size: 4720 bytes --]

[-- Attachment #2: Type: text/plain, Size: 60 bytes --]


-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

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

[Ralph Siemsen]

On Sun, Sep 26, 2021 at 03:39:35PM +0800, Li Wang wrote:
>
>However, unlimit tmpfs-size does not mean set .dev_min_size to zero.
>It should be returned mnt_data directly in limit_tmpfs_mount_size.
>That also does the 20210524 version.

This was my mistake - I had assumed 0 means unlimited - my apologies.

I have now amended the limit_tmpfs_mount_size() function as suggested.
And also the other two suggestions from your follow-up emails.

The tmpfs test now appears to be passing.

Regards,
Ralph

OMMAND:    /opt/ltp/bin/ltp-pan -q  -e -S   -a 1939     -n 1939 -p -f /ltp-tmp/ltp-NH5QtKmmxA/alltests -l /home/root/test-definitions/automated/linux/ltp/output/LTP_syscalls.log  -C 
/home/root/test-definitions/automated/linux/ltp/output/LTP_syscalls.failed -T /opt/ltp/output/LTP_RUN_ON-LTP_syscalls.log.tconf
INFO: Restricted to fallocate05
LOG File: /home/root/test-definitions/automated/linux/ltp/output/LTP_syscalls.log
FAILED COMMAND File: /home/root/test-definitions/automated/linux/ltp/output/LTP_syscalls.failed
TCONF COMMAND File: /opt/ltp/output/LTP_RUN_ON-LTP_syscalls.log.tconf
Running tests.......
tst_device.c:88: TINFO: Found free device 0 '/dev/loop0'
tst_supported_fs_types.c:147: TINFO: Skipping ext2 as requested by the test
tst_supported_fs_types.c:147: TINFO: Skipping ext3 as requested by the test
tst_supported_fs_types.c:147: TINFO: Skipping ext4 as requested by the test
tst_supported_fs_types.c:147: TINFO: Skipping xfs as requested by the test
tst_supported_fs_types.c:147: TINFO: Skipping btrfs as requested by the test
tst_supported_fs_types.c:147: TINFO: Skipping vfat as requested by the test
tst_supported_fs_types.c:115: TINFO: Filesystem exfat is not supported
tst_supported_fs_types.c:147: TINFO: Skipping ntfs as requested by the test
tst_supported_fs_types.c:89: TINFO: Kernel supports tmpfs
tst_supported_fs_types.c:38: TINFO: mkfs is not needed for tmpfs
tst_test.c:1433: TINFO: Testing on tmpfs
tst_test.c:934: TINFO: Skipping mkfs for TMPFS filesystem
tst_test.c:1365: TINFO: Timeout per run is 0h 15m 00s
devtmpfs    on  /dev                                        type  devtmpfs    (rw,relatime,size=87560k,nr_inodes=21890,mode=755)
tmpfs       on  /dev/shm                                    type  tmpfs       (rw,nosuid,nodev)
tmpfs       on  /run                                        type  tmpfs       (rw,nosuid,nodev,mode=755)
tmpfs       on  /sys/fs/cgroup                              type  tmpfs       (ro,nosuid,nodev,noexec,mode=755)
tmpfs       on  /tmp                                        type  tmpfs       (rw,nosuid,nodev)
tmpfs       on  /var/volatile                               type  tmpfs       (rw,relatime)
tmpfs       on  /run/user/0                                 type  tmpfs       (rw,nosuid,nodev,relatime,size=17716k,mode=700)
ltp-tmpfs   on  /ltp-tmp/ltp-NH5QtKmmxA/falDMCkys/mntpoint  type  tmpfs       (rw,relatime)
tst_fill_fs.c:32: TINFO: Creating file mntpoint/file0 size 21710183
tst_fill_fs.c:32: TINFO: Creating file mntpoint/file1 size 8070086
tst_fill_fs.c:32: TINFO: Creating file mntpoint/file2 size 3971177
tst_fill_fs.c:32: TINFO: Creating file mntpoint/file3 size 36915315
tst_fill_fs.c:32: TINFO: Creating file mntpoint/file4 size 70310993
tst_fill_fs.c:59: TINFO: write(): ENOSPC (28)
fallocate05.c:83: TPASS: write() wrote 1048576 bytes
fallocate05.c:104: TINFO: fallocate()d 0 extra blocks on full FS
fallocate05.c:116: TPASS: fallocate() on full FS
fallocate05.c:132: TPASS: fallocate(FALLOC_FL_PUNCH_HOLE | FALLOC_FL_KEEP_SIZE)
fallocate05.c:138: TPASS: write()

Summary:
passed   4
failed   0
broken   0
skipped  0
warnings 0


-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

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

[Li Wang]

[-- Attachment #1.1: Type: text/plain, Size: 1223 bytes --]

On Thu, Sep 23, 2021 at 10:32 PM Cyril Hrubis <chrubis@suse.cz> wrote:

> Hi!
> FYI I've tried to run syscalls on a VM with 256MB RAM just to see what
> explodes and it looks like futex_cmp_requeue01 fails as well because we
> don't have enough memory to fork 1000 processes. I guess that we really
> need an API for at least rough scaling for the number of processes we
> can run based on free memory. With that we could finally fix the
> msgstress testcases as well.
>

+1 Sounds good.

[Cc Fang Ping]

Btw, AFAIK, pifang@ is working on an SUT ability(io, memory, ..) evaluation
before running the test, then set test parameters intelligently according
to the
lite benchmark result. This will definitely help make a proper runtest file
for LTP,
but I'm not sure if he plans to integrate it in LTP internally.

I will talk to him to learn more details.

>
> Also it seems that in my case the tmpfs returns ENOSPC correctly when
> the machine free memory gets low enough regardless of the limit set at
> the mount time, and that's 4.19.0-16-amd64. So I guess that there may be
> something wrong in the kernel you are testing after all.
>

Maybe yes, so I send request for more info of Ralph's system.

-- 
Regards,
Li Wang

[-- Attachment #1.2: Type: text/html, Size: 2598 bytes --]

[-- Attachment #2: Type: text/plain, Size: 60 bytes --]


-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

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

[Cyril Hrubis]

Hi!
> > FYI I've tried to run syscalls on a VM with 256MB RAM just to see what
> > explodes and it looks like futex_cmp_requeue01 fails as well because we
> > don't have enough memory to fork 1000 processes. I guess that we really
> > need an API for at least rough scaling for the number of processes we
> > can run based on free memory. With that we could finally fix the
> > msgstress testcases as well.
> >
> 
> +1 Sounds good.
> 
> [Cc Fang Ping]
> 
> Btw, AFAIK, pifang@ is working on an SUT ability(io, memory, ..) evaluation
> before running the test, then set test parameters intelligently according
> to the
> lite benchmark result. This will definitely help make a proper runtest file
> for LTP,
> but I'm not sure if he plans to integrate it in LTP internally.
> 
> I will talk to him to learn more details.

This is a complex problem, but for now I guess that putting the logic in
the test library would be easiest solution, that allows the tests at
least skip subset of scenarios.

In the long term I guess that the logic can be put into runltp-ng but I
do not think that we can make it work anytime soon. At least this would
require definition of some kind of (JSON based) API that would explain
the test parameters to the testrunner.

-- 
Cyril Hrubis
chrubis@suse.cz

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

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

[Li Wang]

[-- Attachment #1.1: Type: text/plain, Size: 304 bytes --]

> I do not think that it's a good idea to pass ~100MB buffer to a single
> write()
> and expect it to succeed anyways.
>

I suddenly realized that it is 1MB buffer but not 100MB, so that block
number
is not the key point for OOM.

1 Block == 4k on x86_64,
256 * 4k == 1024kB == 1MB

-- 
Regards,
Li Wang

[-- Attachment #1.2: Type: text/html, Size: 991 bytes --]

[-- Attachment #2: Type: text/plain, Size: 60 bytes --]


-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

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

[Cyril Hrubis]

Hi!
> > I do not think that it's a good idea to pass ~100MB buffer to a single
> > write()
> > and expect it to succeed anyways.
> >
> 
> I suddenly realized that it is 1MB buffer but not 100MB, so that block
> number
> is not the key point for OOM.
> 
> 1 Block == 4k on x86_64,
> 256 * 4k == 1024kB == 1MB

Uff my bad. Indeed the problem is the tmpfs that have been added to the
list of filesystems to test recently.

-- 
Cyril Hrubis
chrubis@suse.cz

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp