All of lore.kernel.org
 help / color / mirror / Atom feed
* [LTP] [PATCH RFC 1/3] min_free_kbytes: Fix child exit status check conditions
@ 2019-03-19  9:38 Li Wang
  2019-03-19  9:38 ` [LTP] [PATCH RFC 2/3] min_free_kbytes: enable check_monitor in background Li Wang
  2019-03-19 16:30 ` [LTP] [PATCH RFC 1/3] min_free_kbytes: Fix child exit status check conditions Jan Stancek
  0 siblings, 2 replies; 6+ messages in thread
From: Li Wang @ 2019-03-19  9:38 UTC (permalink / raw)
  To: ltp

From: Vipin K Parashar <vipin@linux.vnet.ibm.com>

Fixes: #349

min_free_kbytes test has badly formed if conditions in mem_tune()
for child exit status check. This is causing test to declare as FAILED
despite that not being the case. Fix child exit status check conditions.

---ERROR LOG---
<..snip..>
mem.c:839: INFO: set overcommit_memory to 1
mem.c:839: INFO: set min_free_kbytes to 11580
memfree is 6974720 kB before eatup mem
memfree is 15488 kB after eatup mem
min_free_kbytes.c:135: FAIL: child unexpectedly failed: 0
mem.c:839: INFO: set min_free_kbytes to 23160
memfree is 7104128 kB before eatup mem
memfree is 26560 kB after eatup mem
min_free_kbytes.c:135: FAIL: child unexpectedly failed: 0
mem.c:839: INFO: set min_free_kbytes to 145812
memfree is 7101504 kB before eatup mem
memfree is 215872 kB after eatup mem
min_free_kbytes.c:135: FAIL: child unexpectedly failed: 0
min_free_kbytes.c:81: PASS: min_free_kbytes test pass
mem.c:839: INFO: set min_free_kbytes to 11580
---------------

Signed-off-by: Vipin K Parashar <vipin@linux.vnet.ibm.com>
Signed-off-by: Li Wang <liwang@redhat.com>
Cc: Jan Stancek <jstancek@redhat.com>
---
 .../kernel/mem/tunable/min_free_kbytes.c      | 40 +++++--------------
 1 file changed, 11 insertions(+), 29 deletions(-)

diff --git a/testcases/kernel/mem/tunable/min_free_kbytes.c b/testcases/kernel/mem/tunable/min_free_kbytes.c
index f114dc493..d2378a700 100644
--- a/testcases/kernel/mem/tunable/min_free_kbytes.c
+++ b/testcases/kernel/mem/tunable/min_free_kbytes.c
@@ -119,39 +119,21 @@ static void test_tune(unsigned long overcommit_policy)
 
 		SAFE_WAITPID(pid[i], &status, WUNTRACED | WCONTINUED);
 
-		if (overcommit_policy == 2) {
-			if (!WIFEXITED(status) || WEXITSTATUS(status) != 0)
-				tst_res(TFAIL,
-					 "child unexpectedly failed: %d",
-					 status);
-		} else if (overcommit_policy == 1) {
-			if (!WIFSIGNALED(status) || WTERMSIG(status) != SIGKILL)
+		if (WIFEXITED(status) && WEXITSTATUS(status) != 0) {
+			tst_res(TFAIL,
+				"child unexpectedly failed: %d", status);
+		} else if (WIFSIGNALED(status) && WTERMSIG(status) != SIGKILL) {
 #if __WORDSIZE == 32
-			{
-				if (total_mem < 3145728UL)
+			if (total_mem < 3145728UL)
 #endif
-					tst_res(TFAIL,
-						 "child unexpectedly failed: %d",
-						 status);
+				tst_res(TFAIL,
+					"child unexpectedly failed: %d", status);
 #if __WORDSIZE == 32
-				/* in 32-bit system, a process allocate about 3Gb memory@most */
-				else
-					tst_res(TINFO, "Child can't allocate "
-						 ">3Gb memory in 32bit system");
-			}
+			/* in 32-bit system, a process allocate about 3Gb memory at most */
+			else
+				tst_res(TINFO, "Child can't allocate "
+					">3Gb memory in 32bit system");
 #endif
-		} else {
-			if (WIFEXITED(status)) {
-				if (WEXITSTATUS(status) != 0) {
-					tst_res(TFAIL, "child unexpectedly "
-						 "failed: %d", status);
-				}
-			} else if (!WIFSIGNALED(status) ||
-				   WTERMSIG(status) != SIGKILL) {
-				tst_res(TFAIL,
-					 "child unexpectedly failed: %d",
-					 status);
-			}
 		}
 	}
 }
-- 
2.20.1


^ permalink raw reply related	[flat|nested] 6+ messages in thread

* [LTP] [PATCH RFC 2/3] min_free_kbytes: enable check_monitor in background
  2019-03-19  9:38 [LTP] [PATCH RFC 1/3] min_free_kbytes: Fix child exit status check conditions Li Wang
@ 2019-03-19  9:38 ` Li Wang
  2019-03-19  9:38   ` [LTP] [PATCH RFC 3/3] min_free_kbytes: allow MemFree to fluctuate nearby min_pages Li Wang
  2019-03-19 16:30 ` [LTP] [PATCH RFC 1/3] min_free_kbytes: Fix child exit status check conditions Jan Stancek
  1 sibling, 1 reply; 6+ messages in thread
From: Li Wang @ 2019-03-19  9:38 UTC (permalink / raw)
  To: ltp

Also:
  do i+=pagesize to make test write page faster
  cleanup work

Signed-off-by: Li Wang <liwang@redhat.com>
---
 .../kernel/mem/tunable/min_free_kbytes.c      | 30 ++++++++-----------
 1 file changed, 13 insertions(+), 17 deletions(-)

diff --git a/testcases/kernel/mem/tunable/min_free_kbytes.c b/testcases/kernel/mem/tunable/min_free_kbytes.c
index d2378a700..2eb51bf66 100644
--- a/testcases/kernel/mem/tunable/min_free_kbytes.c
+++ b/testcases/kernel/mem/tunable/min_free_kbytes.c
@@ -38,7 +38,7 @@
 
 #define MAP_SIZE (1UL<<20)
 
-volatile int end;
+static volatile int end;
 static long default_tune = -1;
 static long orig_overcommit = -1;
 static unsigned long total_mem;
@@ -83,8 +83,7 @@ static void min_free_kbytes_test(void)
 
 static void test_tune(unsigned long overcommit_policy)
 {
-	int status;
-	int pid[3];
+	int status, pid;
 	int ret, i;
 	unsigned long tune, memfree, memtotal;
 
@@ -97,7 +96,7 @@ static void test_tune(unsigned long overcommit_policy)
 		/* case2 */
 		else if (i == 1) {
 			set_sys_tune("min_free_kbytes", 2 * default_tune, 1);
-			/* case3 */
+		/* case3 */
 		} else {
 			memfree = SAFE_READ_MEMINFO("MemFree:");
 			memtotal = SAFE_READ_MEMINFO("MemTotal:");
@@ -109,15 +108,13 @@ static void test_tune(unsigned long overcommit_policy)
 		}
 
 		fflush(stdout);
-		switch (pid[i] = fork()) {
-		case -1:
-			tst_brk(TBROK | TERRNO, "fork");
-		case 0:
+		pid = SAFE_FORK();
+		if (pid == 0) {
 			ret = eatup_mem(overcommit_policy);
 			exit(ret);
 		}
 
-		SAFE_WAITPID(pid[i], &status, WUNTRACED | WCONTINUED);
+		SAFE_WAITPID(pid, &status, WUNTRACED | WCONTINUED);
 
 		if (WIFEXITED(status) && WEXITSTATUS(status) != 0) {
 			tst_res(TFAIL,
@@ -141,11 +138,10 @@ static void test_tune(unsigned long overcommit_policy)
 static int eatup_mem(unsigned long overcommit_policy)
 {
 	int ret = 0;
-	unsigned long memfree;
-	void *addrs;
+	char *addrs;
+	unsigned long i, pagesz = getpagesize();
 
-	memfree = SAFE_READ_MEMINFO("MemFree:");
-	printf("memfree is %lu kB before eatup mem\n", memfree);
+	tst_res(TINFO, "memfree is %lu kB before eatup mem", SAFE_READ_MEMINFO("MemFree:"));
 	while (1) {
 		addrs = mmap(NULL, MAP_SIZE, PROT_READ | PROT_WRITE,
 			     MAP_ANONYMOUS | MAP_PRIVATE, -1, 0);
@@ -156,10 +152,10 @@ static int eatup_mem(unsigned long overcommit_policy)
 			}
 			break;
 		}
-		memset(addrs, 1, MAP_SIZE);
+		for (i = 0; i < MAP_SIZE; i += pagesz)
+			*(addrs + i) = 'a';
 	}
-	memfree = SAFE_READ_MEMINFO("MemFree:");
-	printf("memfree is %lu kB after eatup mem\n", memfree);
+	tst_res(TINFO, "memfree is %lu kB after eatup mem", SAFE_READ_MEMINFO("MemFree:"));
 
 	return ret;
 }
@@ -169,7 +165,7 @@ static void check_monitor(void)
 	unsigned long tune;
 	unsigned long memfree;
 
-	while (end) {
+	while (!end) {
 		memfree = SAFE_READ_MEMINFO("MemFree:");
 		tune = get_sys_tune("min_free_kbytes");
 
-- 
2.20.1


^ permalink raw reply related	[flat|nested] 6+ messages in thread

* [LTP] [PATCH RFC 3/3] min_free_kbytes: allow MemFree to fluctuate nearby min_pages
  2019-03-19  9:38 ` [LTP] [PATCH RFC 2/3] min_free_kbytes: enable check_monitor in background Li Wang
@ 2019-03-19  9:38   ` Li Wang
  0 siblings, 0 replies; 6+ messages in thread
From: Li Wang @ 2019-03-19  9:38 UTC (permalink / raw)
  To: ltp

After enabling the check_monitor in last commit, I got many failures in this
test, that's because it detects the system MemFree is less than min_free_kbytes
at some moments then reprot FAIL.

  ----ERROR LOG----
  min_free_kbytes.c:197: INFO: MemFree is 180032 kB, min_free_kbytes is 180224 kB
  min_free_kbytes.c:198: FAIL: MemFree < min_free_kbytes
  min_free_kbytes.c:197: INFO: MemFree is 179520 kB, min_free_kbytes is 180224 kB
  min_free_kbytes.c:198: FAIL: MemFree < min_free_kbytes
  min_free_kbytes.c:197: INFO: MemFree is 176704 kB, min_free_kbytes is 180224 kB
  min_free_kbytes.c:198: FAIL: MemFree < min_free_kbytes
  min_free_kbytes.c:197: INFO: MemFree is 176448 kB, min_free_kbytes is 180224 kB
  min_free_kbytes.c:198: FAIL: MemFree < min_free_kbytes
  min_free_kbytes.c:197: INFO: MemFree is 178880 kB, min_free_kbytes is 180224 kB
  min_free_kbytes.c:198: FAIL: MemFree < min_free_kbytes
  min_free_kbytes.c:197: INFO: MemFree is 174656 kB, min_free_kbytes is 180224 kB
  min_free_kbytes.c:198: FAIL: MemFree < min_free_kbytes
  -----------------

But I dont' think it's a kernel bug, since to compare MemFree with min_free_kbytes
is NOT accurate in memory testing.

Theoretically, min_free_kbytes is using for memory watermark setting. When memory
in a certain zone drops below 'low' watermark, the kernel starts to reclaim memory,
until there is again more than 'high' available memory. However, while the memory
is less than 'min' watermark, only GFP_ATOMIC allocations are satisfied, everything
else results in OOM.

In this patch, the MemFree is allowed to fluctuate nearby min_free_kbytes, the main
idea is to give a little accessible range (min_free_kbytes - 1/10*min_free_kbytes)
for MemFree comparing. Otherwise this testcase is meaningless, or we can remove it
from LTP.

MORE REFERENCE INFO:

Those watermarks behave accordingly to the picture below:

    ^
    |
  f | \                  /
  r |  \                /[3]
  e |...\............../................
  e |    \ [0]        /       high_pages
    |     \          /
  p |......\......../...................
  a |       \[1]   /           low_pages
  g |        \    /
  e |.........\../......................
  s |          \/[2]           min_pages
    |
    +------------------------------------>
                    time

Memory is being allocated normally at [0] and [1]. When hash of free pages within a zone
decreases below low_pages [1], kswapd is woken up to start scanning memory for reclamation.

If the allocation load out-paces kswapd and the free memory level drops below min_pages [2]
only ATOMIC allocations are granted and every other task in the system requesting memory
starts doing the same work kswapd does -- putting the system into direct reclaim mode.
Direct reclaim ceases as soon as the free memory level is restored to above min_pages [2]

high_pages [3] marks the point where kswapd goes back to sleep as there's no more reclaim
work to be done.

Signed-off-by: Li Wang <liwang@redhat.com>
Cc: Rafael Aquini <aquini@redhat.com>
---
 testcases/kernel/mem/tunable/min_free_kbytes.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/testcases/kernel/mem/tunable/min_free_kbytes.c b/testcases/kernel/mem/tunable/min_free_kbytes.c
index 2eb51bf66..6b7da2215 100644
--- a/testcases/kernel/mem/tunable/min_free_kbytes.c
+++ b/testcases/kernel/mem/tunable/min_free_kbytes.c
@@ -169,7 +169,10 @@ static void check_monitor(void)
 		memfree = SAFE_READ_MEMINFO("MemFree:");
 		tune = get_sys_tune("min_free_kbytes");
 
-		if (memfree < tune) {
+		/* The MemFree is allowed to fluctuate nearby min_free_kbytes,
+		 * here is to give a little accessible range(min_free_kbytes -
+		 * 1/10 * min_free_kbytes) for MemFree comparing. */
+		if ((memfree + 1/10*tune) < tune) {
 			tst_res(TINFO, "MemFree is %lu kB, "
 				 "min_free_kbytes is %lu kB", memfree, tune);
 			tst_res(TFAIL, "MemFree < min_free_kbytes");
-- 
2.20.1


^ permalink raw reply related	[flat|nested] 6+ messages in thread

* [LTP] [PATCH RFC 1/3] min_free_kbytes: Fix child exit status check conditions
  2019-03-19  9:38 [LTP] [PATCH RFC 1/3] min_free_kbytes: Fix child exit status check conditions Li Wang
  2019-03-19  9:38 ` [LTP] [PATCH RFC 2/3] min_free_kbytes: enable check_monitor in background Li Wang
@ 2019-03-19 16:30 ` Jan Stancek
  2019-03-20  6:11   ` Li Wang
  1 sibling, 1 reply; 6+ messages in thread
From: Jan Stancek @ 2019-03-19 16:30 UTC (permalink / raw)
  To: ltp



----- Original Message -----
> From: Vipin K Parashar <vipin@linux.vnet.ibm.com>
> 
> Fixes: #349
> 
> min_free_kbytes test has badly formed if conditions in mem_tune()
> for child exit status check. 

Can you please elaborate what's wrong about it?

> This is causing test to declare as FAILED
> despite that not being the case.

Why? Shouldn't mmap succeed with overcommit == 1?

> Fix child exit status check conditions.
> 
> ---ERROR LOG---
> <..snip..>
> mem.c:839: INFO: set overcommit_memory to 1
> mem.c:839: INFO: set min_free_kbytes to 11580
> memfree is 6974720 kB before eatup mem
> memfree is 15488 kB after eatup mem
> min_free_kbytes.c:135: FAIL: child unexpectedly failed: 0
> mem.c:839: INFO: set min_free_kbytes to 23160
> memfree is 7104128 kB before eatup mem
> memfree is 26560 kB after eatup mem
> min_free_kbytes.c:135: FAIL: child unexpectedly failed: 0
> mem.c:839: INFO: set min_free_kbytes to 145812
> memfree is 7101504 kB before eatup mem
> memfree is 215872 kB after eatup mem
> min_free_kbytes.c:135: FAIL: child unexpectedly failed: 0
> min_free_kbytes.c:81: PASS: min_free_kbytes test pass
> mem.c:839: INFO: set min_free_kbytes to 11580
> ---------------
> 
> Signed-off-by: Vipin K Parashar <vipin@linux.vnet.ibm.com>
> Signed-off-by: Li Wang <liwang@redhat.com>
> Cc: Jan Stancek <jstancek@redhat.com>
> ---
>  .../kernel/mem/tunable/min_free_kbytes.c      | 40 +++++--------------
>  1 file changed, 11 insertions(+), 29 deletions(-)
> 
> diff --git a/testcases/kernel/mem/tunable/min_free_kbytes.c
> b/testcases/kernel/mem/tunable/min_free_kbytes.c
> index f114dc493..d2378a700 100644
> --- a/testcases/kernel/mem/tunable/min_free_kbytes.c
> +++ b/testcases/kernel/mem/tunable/min_free_kbytes.c
> @@ -119,39 +119,21 @@ static void test_tune(unsigned long overcommit_policy)
>  
>  		SAFE_WAITPID(pid[i], &status, WUNTRACED | WCONTINUED);
>  
> -		if (overcommit_policy == 2) {
> -			if (!WIFEXITED(status) || WEXITSTATUS(status) != 0)
> -				tst_res(TFAIL,
> -					 "child unexpectedly failed: %d",
> -					 status);
> -		} else if (overcommit_policy == 1) {
> -			if (!WIFSIGNALED(status) || WTERMSIG(status) != SIGKILL)
> +		if (WIFEXITED(status) && WEXITSTATUS(status) != 0) {
> +			tst_res(TFAIL,
> +				"child unexpectedly failed: %d", status);
> +		} else if (WIFSIGNALED(status) && WTERMSIG(status) != SIGKILL) {
>  #if __WORDSIZE == 32
> -			{
> -				if (total_mem < 3145728UL)
> +			if (total_mem < 3145728UL)
>  #endif
> -					tst_res(TFAIL,
> -						 "child unexpectedly failed: %d",
> -						 status);
> +				tst_res(TFAIL,
> +					"child unexpectedly failed: %d", status);
>  #if __WORDSIZE == 32
> -				/* in 32-bit system, a process allocate about 3Gb memory at most */
> -				else
> -					tst_res(TINFO, "Child can't allocate "
> -						 ">3Gb memory in 32bit system");
> -			}
> +			/* in 32-bit system, a process allocate about 3Gb memory at most */
> +			else
> +				tst_res(TINFO, "Child can't allocate "
> +					">3Gb memory in 32bit system");
>  #endif
> -		} else {
> -			if (WIFEXITED(status)) {
> -				if (WEXITSTATUS(status) != 0) {
> -					tst_res(TFAIL, "child unexpectedly "
> -						 "failed: %d", status);
> -				}
> -			} else if (!WIFSIGNALED(status) ||
> -				   WTERMSIG(status) != SIGKILL) {
> -				tst_res(TFAIL,
> -					 "child unexpectedly failed: %d",
> -					 status);
> -			}
>  		}
>  	}
>  }
> --
> 2.20.1
> 
> 

^ permalink raw reply	[flat|nested] 6+ messages in thread

* [LTP] [PATCH RFC 1/3] min_free_kbytes: Fix child exit status check conditions
  2019-03-19 16:30 ` [LTP] [PATCH RFC 1/3] min_free_kbytes: Fix child exit status check conditions Jan Stancek
@ 2019-03-20  6:11   ` Li Wang
  2019-03-20  8:10     ` Jan Stancek
  0 siblings, 1 reply; 6+ messages in thread
From: Li Wang @ 2019-03-20  6:11 UTC (permalink / raw)
  To: ltp

@Vipin, is there any possible you can have a look Jan's question?

On Wed, Mar 20, 2019 at 12:30 AM Jan Stancek <jstancek@redhat.com> wrote:

>
>
> ----- Original Message -----
> > From: Vipin K Parashar <vipin@linux.vnet.ibm.com>
> >
> > Fixes: #349
> >
> > min_free_kbytes test has badly formed if conditions in mem_tune()
> > for child exit status check.
>
> Can you please elaborate what's wrong about it?
>

I‘m not sure if Vipin could help to explain this. I just nocited that this
pull request was pending there more than half year, so I re-send this patch
to ML for more discussion.
https://github.com/linux-test-project/ltp/pull/350


> > This is causing test to declare as FAILED
> > despite that not being the case.
>
> Why? Shouldn't mmap succeed with overcommit == 1?
>

I was unable to reproduce this. But AFAIK, 'overcommit == 1' cann't
guarantee the MAP_FAILED(with ENOMEM) before oom. So I roughly made change
in the original patch to catch up both oom and map_failed scenario for any
'overcommit'.

Beside that, as I was pointed out in patch 3/3, this test has an obviously
defect in design, I'm also not sure if MemFree + (1/10 *min_free_kbytes) is
safty enough, but that's only what I can do for the case remedy.


> > Fix child exit status check conditions.
> >
> > ---ERROR LOG---
> > <..snip..>
> > mem.c:839: INFO: set overcommit_memory to 1
> > mem.c:839: INFO: set min_free_kbytes to 11580
> > memfree is 6974720 kB before eatup mem
> > memfree is 15488 kB after eatup mem
> > min_free_kbytes.c:135: FAIL: child unexpectedly failed: 0
> > mem.c:839: INFO: set min_free_kbytes to 23160
> > memfree is 7104128 kB before eatup mem
> > memfree is 26560 kB after eatup mem
> > min_free_kbytes.c:135: FAIL: child unexpectedly failed: 0
> > mem.c:839: INFO: set min_free_kbytes to 145812
> > memfree is 7101504 kB before eatup mem
> > memfree is 215872 kB after eatup mem
> > min_free_kbytes.c:135: FAIL: child unexpectedly failed: 0
> > min_free_kbytes.c:81: PASS: min_free_kbytes test pass
> > mem.c:839: INFO: set min_free_kbytes to 11580
> > ---------------
> >
> > Signed-off-by: Vipin K Parashar <vipin@linux.vnet.ibm.com>
> > Signed-off-by: Li Wang <liwang@redhat.com>
> > Cc: Jan Stancek <jstancek@redhat.com>
> > ---
> >  .../kernel/mem/tunable/min_free_kbytes.c      | 40 +++++--------------
> >  1 file changed, 11 insertions(+), 29 deletions(-)
> >
> > diff --git a/testcases/kernel/mem/tunable/min_free_kbytes.c
> > b/testcases/kernel/mem/tunable/min_free_kbytes.c
> > index f114dc493..d2378a700 100644
> > --- a/testcases/kernel/mem/tunable/min_free_kbytes.c
> > +++ b/testcases/kernel/mem/tunable/min_free_kbytes.c
> > @@ -119,39 +119,21 @@ static void test_tune(unsigned long
> overcommit_policy)
> >
> >               SAFE_WAITPID(pid[i], &status, WUNTRACED | WCONTINUED);
> >
> > -             if (overcommit_policy == 2) {
> > -                     if (!WIFEXITED(status) || WEXITSTATUS(status) != 0)
> > -                             tst_res(TFAIL,
> > -                                      "child unexpectedly failed: %d",
> > -                                      status);
> > -             } else if (overcommit_policy == 1) {
> > -                     if (!WIFSIGNALED(status) || WTERMSIG(status) !=
> SIGKILL)
> > +             if (WIFEXITED(status) && WEXITSTATUS(status) != 0) {
> > +                     tst_res(TFAIL,
> > +                             "child unexpectedly failed: %d", status);
> > +             } else if (WIFSIGNALED(status) && WTERMSIG(status) !=
> SIGKILL) {
> >  #if __WORDSIZE == 32
> > -                     {
> > -                             if (total_mem < 3145728UL)
> > +                     if (total_mem < 3145728UL)
> >  #endif
> > -                                     tst_res(TFAIL,
> > -                                              "child unexpectedly
> failed: %d",
> > -                                              status);
> > +                             tst_res(TFAIL,
> > +                                     "child unexpectedly failed: %d",
> status);
> >  #if __WORDSIZE == 32
> > -                             /* in 32-bit system, a process allocate
> about 3Gb memory at most */
> > -                             else
> > -                                     tst_res(TINFO, "Child can't
> allocate "
> > -                                              ">3Gb memory in 32bit
> system");
> > -                     }
> > +                     /* in 32-bit system, a process allocate about 3Gb
> memory at most */
> > +                     else
> > +                             tst_res(TINFO, "Child can't allocate "
> > +                                     ">3Gb memory in 32bit system");
> >  #endif
> > -             } else {
> > -                     if (WIFEXITED(status)) {
> > -                             if (WEXITSTATUS(status) != 0) {
> > -                                     tst_res(TFAIL, "child unexpectedly
> "
> > -                                              "failed: %d", status);
> > -                             }
> > -                     } else if (!WIFSIGNALED(status) ||
> > -                                WTERMSIG(status) != SIGKILL) {
> > -                             tst_res(TFAIL,
> > -                                      "child unexpectedly failed: %d",
> > -                                      status);
> > -                     }
> >               }
> >       }
> >  }
> > --
> > 2.20.1
> >
> >
>


-- 
Regards,
Li Wang
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linux.it/pipermail/ltp/attachments/20190320/7ddf0f55/attachment-0001.html>

^ permalink raw reply	[flat|nested] 6+ messages in thread

* [LTP] [PATCH RFC 1/3] min_free_kbytes: Fix child exit status check conditions
  2019-03-20  6:11   ` Li Wang
@ 2019-03-20  8:10     ` Jan Stancek
  0 siblings, 0 replies; 6+ messages in thread
From: Jan Stancek @ 2019-03-20  8:10 UTC (permalink / raw)
  To: ltp



----- Original Message -----
> @Vipin, is there any possible you can have a look Jan's question?
> 
> On Wed, Mar 20, 2019 at 12:30 AM Jan Stancek <jstancek@redhat.com> wrote:
> 
> >
> >
> > ----- Original Message -----
> > > From: Vipin K Parashar <vipin@linux.vnet.ibm.com>
> > >
> > > Fixes: #349
> > >
> > > min_free_kbytes test has badly formed if conditions in mem_tune()
> > > for child exit status check.
> >
> > Can you please elaborate what's wrong about it?
> >
> 
> I‘m not sure if Vipin could help to explain this. I just nocited that this
> pull request was pending there more than half year, so I re-send this patch
> to ML for more discussion.
> https://github.com/linux-test-project/ltp/pull/350
> 
> 
> > > This is causing test to declare as FAILED
> > > despite that not being the case.
> >
> > Why? Shouldn't mmap succeed with overcommit == 1?
> >
> 
> I was unable to reproduce this. But AFAIK, 'overcommit == 1' cann't
> guarantee the MAP_FAILED(with ENOMEM) before oom.

With 'overcommit == 1' test always expects OOM. Test output below
suggests that child ended normally, because mmap failed.

> So I roughly made change
> in the original patch to catch up both oom and map_failed scenario for any
> 'overcommit'.
> 
> Beside that, as I was pointed out in patch 3/3, this test has an obviously
> defect in design, I'm also not sure if MemFree + (1/10 *min_free_kbytes) is
> safty enough, but that's only what I can do for the case remedy.
> 
> 
> > > Fix child exit status check conditions.
> > >
> > > ---ERROR LOG---
> > > <..snip..>
> > > mem.c:839: INFO: set overcommit_memory to 1
> > > mem.c:839: INFO: set min_free_kbytes to 11580
> > > memfree is 6974720 kB before eatup mem
> > > memfree is 15488 kB after eatup mem
> > > min_free_kbytes.c:135: FAIL: child unexpectedly failed: 0
> > > mem.c:839: INFO: set min_free_kbytes to 23160
> > > memfree is 7104128 kB before eatup mem
> > > memfree is 26560 kB after eatup mem
> > > min_free_kbytes.c:135: FAIL: child unexpectedly failed: 0
> > > mem.c:839: INFO: set min_free_kbytes to 145812
> > > memfree is 7101504 kB before eatup mem
> > > memfree is 215872 kB after eatup mem
> > > min_free_kbytes.c:135: FAIL: child unexpectedly failed: 0
> > > min_free_kbytes.c:81: PASS: min_free_kbytes test pass
> > > mem.c:839: INFO: set min_free_kbytes to 11580
> > > ---------------
> > >
> > > Signed-off-by: Vipin K Parashar <vipin@linux.vnet.ibm.com>
> > > Signed-off-by: Li Wang <liwang@redhat.com>
> > > Cc: Jan Stancek <jstancek@redhat.com>
> > > ---
> > >  .../kernel/mem/tunable/min_free_kbytes.c      | 40 +++++--------------
> > >  1 file changed, 11 insertions(+), 29 deletions(-)
> > >
> > > diff --git a/testcases/kernel/mem/tunable/min_free_kbytes.c
> > > b/testcases/kernel/mem/tunable/min_free_kbytes.c
> > > index f114dc493..d2378a700 100644
> > > --- a/testcases/kernel/mem/tunable/min_free_kbytes.c
> > > +++ b/testcases/kernel/mem/tunable/min_free_kbytes.c
> > > @@ -119,39 +119,21 @@ static void test_tune(unsigned long
> > overcommit_policy)
> > >
> > >               SAFE_WAITPID(pid[i], &status, WUNTRACED | WCONTINUED);
> > >
> > > -             if (overcommit_policy == 2) {
> > > -                     if (!WIFEXITED(status) || WEXITSTATUS(status) != 0)
> > > -                             tst_res(TFAIL,
> > > -                                      "child unexpectedly failed: %d",
> > > -                                      status);
> > > -             } else if (overcommit_policy == 1) {
> > > -                     if (!WIFSIGNALED(status) || WTERMSIG(status) !=
> > SIGKILL)
> > > +             if (WIFEXITED(status) && WEXITSTATUS(status) != 0) {
> > > +                     tst_res(TFAIL,
> > > +                             "child unexpectedly failed: %d", status);
> > > +             } else if (WIFSIGNALED(status) && WTERMSIG(status) !=
> > SIGKILL) {
> > >  #if __WORDSIZE == 32
> > > -                     {
> > > -                             if (total_mem < 3145728UL)
> > > +                     if (total_mem < 3145728UL)
> > >  #endif
> > > -                                     tst_res(TFAIL,
> > > -                                              "child unexpectedly
> > failed: %d",
> > > -                                              status);
> > > +                             tst_res(TFAIL,
> > > +                                     "child unexpectedly failed: %d",
> > status);
> > >  #if __WORDSIZE == 32
> > > -                             /* in 32-bit system, a process allocate
> > about 3Gb memory at most */
> > > -                             else
> > > -                                     tst_res(TINFO, "Child can't
> > allocate "
> > > -                                              ">3Gb memory in 32bit
> > system");
> > > -                     }
> > > +                     /* in 32-bit system, a process allocate about 3Gb
> > memory at most */
> > > +                     else
> > > +                             tst_res(TINFO, "Child can't allocate "
> > > +                                     ">3Gb memory in 32bit system");
> > >  #endif
> > > -             } else {
> > > -                     if (WIFEXITED(status)) {
> > > -                             if (WEXITSTATUS(status) != 0) {
> > > -                                     tst_res(TFAIL, "child unexpectedly
> > "
> > > -                                              "failed: %d", status);
> > > -                             }
> > > -                     } else if (!WIFSIGNALED(status) ||
> > > -                                WTERMSIG(status) != SIGKILL) {
> > > -                             tst_res(TFAIL,
> > > -                                      "child unexpectedly failed: %d",
> > > -                                      status);
> > > -                     }
> > >               }
> > >       }
> > >  }
> > > --
> > > 2.20.1
> > >
> > >
> >
> 
> 
> --
> Regards,
> Li Wang
> 

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2019-03-20  8:10 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-03-19  9:38 [LTP] [PATCH RFC 1/3] min_free_kbytes: Fix child exit status check conditions Li Wang
2019-03-19  9:38 ` [LTP] [PATCH RFC 2/3] min_free_kbytes: enable check_monitor in background Li Wang
2019-03-19  9:38   ` [LTP] [PATCH RFC 3/3] min_free_kbytes: allow MemFree to fluctuate nearby min_pages Li Wang
2019-03-19 16:30 ` [LTP] [PATCH RFC 1/3] min_free_kbytes: Fix child exit status check conditions Jan Stancek
2019-03-20  6:11   ` Li Wang
2019-03-20  8:10     ` Jan Stancek

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.