[LTP] [PATCH] madvise06: Do no set swap limit

[LTP] [PATCH] madvise06: Do no set swap limit

[Richard Palethorpe]

Setting the swap limit is unnecessary for this test. By default it
appears to be set to some large value which is OK. Setting it may fail
for reasons unrelated to the test's purpose making the test less
reliable.

Signed-off-by: Richard Palethorpe <rpalethorpe@suse.com>
---

I should not have included this in the first update to the test. It
appears that it fails with EACCES on at least one configuration, where
the test ran previously. Also it could fail with EBUSY in theory.

I don't know why limit_in_bytes can be set, but memsw.limit_in_bytes
results in EACCES. This is interesting, however should be the focus of
a different test IMO.

 testcases/kernel/syscalls/madvise/madvise06.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/testcases/kernel/syscalls/madvise/madvise06.c b/testcases/kernel/syscalls/madvise/madvise06.c
index 817faae39..2ba2bac6f 100644
--- a/testcases/kernel/syscalls/madvise/madvise06.c
+++ b/testcases/kernel/syscalls/madvise/madvise06.c
@@ -46,7 +46,6 @@
 
 #define CHUNK_SZ (400*1024*1024L)
 #define MEM_LIMIT (CHUNK_SZ / 2)
-#define MEMSW_LIMIT (2 * CHUNK_SZ)
 #define PASS_THRESHOLD (CHUNK_SZ / 4)
 #define PASS_THRESHOLD_KB (PASS_THRESHOLD / 1024)
 
@@ -124,8 +123,6 @@ static void setup(void)
 	SAFE_FILE_PRINTF("/proc/self/oom_score_adj", "%d", -1000);
 	SAFE_FILE_PRINTF(MNT_NAME"/"GROUP_NAME"/memory.limit_in_bytes", "%ld\n",
 			 MEM_LIMIT);
-	SAFE_FILE_PRINTF(MNT_NAME"/"GROUP_NAME"/memory.memsw.limit_in_bytes", "%ld\n",
-			 MEMSW_LIMIT);
 	SAFE_FILE_PRINTF(MNT_NAME"/"GROUP_NAME"/memory.swappiness", "60");
 	SAFE_FILE_PRINTF(MNT_NAME"/"GROUP_NAME"/tasks", "%d\n", getpid());
 
-- 
2.29.1

[LTP] [PATCH] madvise06: Do no set swap limit

[Li Wang]

Hi Richard,

On Mon, Nov 16, 2020 at 4:59 PM Richard Palethorpe <rpalethorpe@suse.com>
wrote:

> Setting the swap limit is unnecessary for this test. By default it
> appears to be set to some large value which is OK. Setting it may fail
> for reasons unrelated to the test's purpose making the test less
> reliable.
>

Generally, this is right. And if the 'memory.limit_in_bytes' has been set
successfully, that means the default value of 'memory.memsw.limit_in_bytes'
is bigger than or equal to it.
(an invalid argument error will occur if not like this)

But in this madvise06, set 'memory.memsw.limit_in_bytes' will safer to test.

The reason is to make sure memsw.limit_in_bytes' is bigger(twifold) than
'memory.limit_in_bytes' otherwise it can't be finished as we expected.
(madvise06 will be stuck when memsw.limit_in_bytes < 2 *
memory.limit_in_bytes)


>
> Signed-off-by: Richard Palethorpe <rpalethorpe@suse.com>
> ---
>
> I should not have included this in the first update to the test. It
> appears that it fails with EACCES on at least one configuration, where
> the test ran previously. Also it could fail with EBUSY in theory.
>
> I don't know why limit_in_bytes can be set, but memsw.limit_in_bytes
> results in EACCES. This is interesting, however should be the focus of
> a different test IMO.
>

This sounds like a cgroup issue or related configuration caused.


>
>  testcases/kernel/syscalls/madvise/madvise06.c | 3 ---
>  1 file changed, 3 deletions(-)
>
> diff --git a/testcases/kernel/syscalls/madvise/madvise06.c
> b/testcases/kernel/syscalls/madvise/madvise06.c
> index 817faae39..2ba2bac6f 100644
> --- a/testcases/kernel/syscalls/madvise/madvise06.c
> +++ b/testcases/kernel/syscalls/madvise/madvise06.c
> @@ -46,7 +46,6 @@
>
>  #define CHUNK_SZ (400*1024*1024L)
>  #define MEM_LIMIT (CHUNK_SZ / 2)
> -#define MEMSW_LIMIT (2 * CHUNK_SZ)
>  #define PASS_THRESHOLD (CHUNK_SZ / 4)
>  #define PASS_THRESHOLD_KB (PASS_THRESHOLD / 1024)
>
> @@ -124,8 +123,6 @@ static void setup(void)
>         SAFE_FILE_PRINTF("/proc/self/oom_score_adj", "%d", -1000);
>         SAFE_FILE_PRINTF(MNT_NAME"/"GROUP_NAME"/memory.limit_in_bytes",
> "%ld\n",
>                          MEM_LIMIT);
> -       SAFE_FILE_PRINTF(MNT_NAME"/"GROUP_NAME"/memory.memsw.limit_in_bytes",
> "%ld\n",
> -                        MEMSW_LIMIT);
>         SAFE_FILE_PRINTF(MNT_NAME"/"GROUP_NAME"/memory.swappiness", "60");
>         SAFE_FILE_PRINTF(MNT_NAME"/"GROUP_NAME"/tasks", "%d\n", getpid());
>
> --
> 2.29.1
>
>

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

[LTP] [PATCH] madvise06: Do no set swap limit

[Richard Palethorpe]

Hello,

Li Wang <liwang@redhat.com> writes:

> Hi Richard,
>
> On Mon, Nov 16, 2020 at 4:59 PM Richard Palethorpe <rpalethorpe@suse.com>
> wrote:
>
>> Setting the swap limit is unnecessary for this test. By default it
>> appears to be set to some large value which is OK. Setting it may fail
>> for reasons unrelated to the test's purpose making the test less
>> reliable.
>>
>
> Generally, this is right. And if the 'memory.limit_in_bytes' has been set
> successfully, that means the default value of 'memory.memsw.limit_in_bytes'
> is bigger than or equal to it.
> (an invalid argument error will occur if not like this)
>
> But in this madvise06, set 'memory.memsw.limit_in_bytes' will safer to test.
>
> The reason is to make sure memsw.limit_in_bytes' is bigger(twifold) than
> 'memory.limit_in_bytes' otherwise it can't be finished as we expected.
> (madvise06 will be stuck when memsw.limit_in_bytes < 2 *
> memory.limit_in_bytes)

OK.

>
>
>>
>> Signed-off-by: Richard Palethorpe <rpalethorpe@suse.com>
>> ---
>>
>> I should not have included this in the first update to the test. It
>> appears that it fails with EACCES on at least one configuration, where
>> the test ran previously. Also it could fail with EBUSY in theory.
>>
>> I don't know why limit_in_bytes can be set, but memsw.limit_in_bytes
>> results in EACCES. This is interesting, however should be the focus of
>> a different test IMO.
>>
>
> This sounds like a cgroup issue or related configuration caused.

Yes, it is probably due to the memsw counter being disabled. So I will
send a V2 of the other madvise06 patch.

-- 
Thank you,
Richard.