[LTP] [PATCH V2] madvise09:Update PAGES to a larger value

[LTP] [PATCH V2] madvise09:Update PAGES to a larger value

[shuang.qiu]

From: Shuang Qiu <shuang.qiu@oracle.com>

In upstream patch 1a61ab (mm: memcontrol: replace zone summing with lruvec_page_state()),
it modify the lruvec state in batch,equal and less than 32 MADV_FREE pages will not trigger
the account of lruvec_stat,and will not be free in memory pressure either.
So the testcase may fail with:
...
madvise09.c:219: INFO: Memory hungry child 6178 started, try 10
madvise09.c:254: INFO: Memory map: pppppppppppppppppppppppppppppppp
madvise09.c:259: FAIL: No MADV_FREE page was freed on low memory
...
We should allocate several megabytes to avoid depending kernel implementation details, 
which would mean allocating thousands of pages.
Setting PAGES=970 so that it will just avoid hitting the WARN that "message is too long" 
in tst_res(TINFO, "Memory map: %s", map).

Signed-off-by: Shuang Qiu <shuang.qiu@oracle.com>
---
 testcases/kernel/syscalls/madvise/madvise09.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/testcases/kernel/syscalls/madvise/madvise09.c b/testcases/kernel/syscalls/madvise/madvise09.c
index 01075f6..3759053 100644
--- a/testcases/kernel/syscalls/madvise/madvise09.c
+++ b/testcases/kernel/syscalls/madvise/madvise09.c
@@ -57,7 +57,7 @@ static int sleep_between_faults;
 
 static int swap_accounting_enabled;
 
-#define PAGES 32
+#define PAGES 970
 #define TOUCHED_PAGE1 0
 #define TOUCHED_PAGE2 10
 
-- 
1.9.1

[LTP] [PATCH V2] madvise09:Update PAGES to a larger value

[Li Wang]

Hi Shuang,

Thanks for the quick work on this.

There are two problems that you probably ignored.

1. On ppc64 system, the page size is 64KB, and 970 * 64KB is almost 60MB
which we do allocate. So we'd better raise
the limit_in_bytes/memsw.limit_in_bytes a little in cgroup correspondingly.

2. As Cascardo points out, madvise09 gets retries in an infinite loop when
hitting OOM. That's because, in the run() function, it does not limit the
retry times. We need to take care of this as well.

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

[LTP] [PATCH V2] madvise09:Update PAGES to a larger value

[Cyril Hrubis]

Hi!
> Thanks for the quick work on this.
> 
> There are two problems that you probably ignored.
> 
> 1. On ppc64 system, the page size is 64KB, and 970 * 64KB is almost 60MB
> which we do allocate. So we'd better raise
> the limit_in_bytes/memsw.limit_in_bytes a little in cgroup correspondingly.
> 
> 2. As Cascardo points out, madvise09 gets retries in an infinite loop when
> hitting OOM. That's because, in the run() function, it does not limit the
> retry times. We need to take care of this as well.

I guess that the debug printing would go out of hand as well, 970
characters printed into the console is no fun either. The test needs a
bit more than just bumping the number of pages. However as we are
getting really close to release I guess that the best course of action
would be workarounding the issue for now by bumping the number of pages
to something as 128 pages. Then we can rework the test once LTP has been
released.

-- 
Cyril Hrubis
chrubis@suse.cz

[LTP] [PATCH V2] madvise09:Update PAGES to a larger value

[Li Wang]

On Thu, Sep 12, 2019 at 5:41 PM Cyril Hrubis <chrubis@suse.cz> wrote:

> Hi!
> > Thanks for the quick work on this.
> >
> > There are two problems that you probably ignored.
> >
> > 1. On ppc64 system, the page size is 64KB, and 970 * 64KB is almost 60MB
> > which we do allocate. So we'd better raise
> > the limit_in_bytes/memsw.limit_in_bytes a little in cgroup
> correspondingly.
> >
> > 2. As Cascardo points out, madvise09 gets retries in an infinite loop
> when
> > hitting OOM. That's because, in the run() function, it does not limit the
> > retry times. We need to take care of this as well.
>
> I guess that the debug printing would go out of hand as well, 970
> characters printed into the console is no fun either. The test needs a
> bit more than just bumping the number of pages. However as we are
> getting really close to release I guess that the best course of action
> would be workarounding the issue for now by bumping the number of pages
> to something as 128 pages. Then we can rework the test once LTP has been
> released.
>

OK for me.

-- 
Regards,
Li Wang
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linux.it/pipermail/ltp/attachments/20190912/053bfaca/attachment-0001.htm>