All of lore.kernel.org
 help / color / mirror / Atom feed
* [LTP] [PATCH] mtest01: correct the ALLOC_THRESHOLD definition on s390x
@ 2019-11-28  4:55 Li Wang
  2019-11-29  9:55 ` Petr Vorel
  2019-11-29 12:16 ` Jan Stancek
  0 siblings, 2 replies; 4+ messages in thread
From: Li Wang @ 2019-11-28  4:55 UTC (permalink / raw)
  To: ltp

mtest01 hits a problem on s390x platform. The situation is that if children's
memory allocating is ongoing and the test remaining time is in an emergency, the
parent will break from the while loop and try to revoke children, obviously, it
doesn't have enough time to wait for the children's status change to 'T'. Then it
occurs timeout issue as below:

  mtest01.c:134: INFO: Filling up 80% of free ram which is 5868864 kbytes
  mtest01.c:149: INFO: ... child 38289 starting
  mtest01.c:149: INFO: ... child 38288 starting
  mtest01.c:208: WARN: the remaininig time is not enough for testing
  mtest01.c:218: FAIL: kbytes allocated (and written to) less than expected 5868864
  Test timeouted, sending SIGKILL!

The immediate cause is the memory allocating is too slow to finish fleetly on such
a small virtual s390x machine, because ALLOC_THRESHOLD does not take real effort.
Here let's correct the allocating threshold definition to make sure each child
allocates less memory.

And, another fix for the fail handling. In case children are still on memory
allocating, the remaining 15 seconds is not enough to wait for process status
change. We kill them directly to avoid test timeout occurring.

Signed-off-by: Li Wang <liwang@redhat.com>
Cc: Rachel Sibley <rasibley@redhat.com>
---
 testcases/kernel/mem/mtest01/mtest01.c | 13 +++++++++----
 1 file changed, 9 insertions(+), 4 deletions(-)

diff --git a/testcases/kernel/mem/mtest01/mtest01.c b/testcases/kernel/mem/mtest01/mtest01.c
index 960a2cef8..446d26897 100644
--- a/testcases/kernel/mem/mtest01/mtest01.c
+++ b/testcases/kernel/mem/mtest01/mtest01.c
@@ -33,7 +33,7 @@
 
 #define FIVE_HUNDRED_MB         (500ULL*1024*1024)
 
-#if defined(_s390_)
+#if defined(__s390__) || defined(__s390x__)
 #define ALLOC_THRESHOLD		FIVE_HUNDRED_MB
 #elif defined(TST_ABI32)
 #define ALLOC_THRESHOLD		(2*FIVE_HUNDRED_MB)
@@ -216,11 +216,16 @@ static void mem_test(void)
 	if (children_done < pid_cntr) {
 		tst_res(TFAIL, "kbytes allocated %sless than expected %llu",
 				write_msg, alloc_maxbytes / 1024);
-	} else {
-		tst_res(TPASS, "%llu kbytes allocated %s",
-				alloc_maxbytes / 1024, write_msg);
+
+		for (i = 0; i < pid_cntr; i++)
+			kill(pid_list[i], SIGKILL);
+
+		return;
 	}
 
+	tst_res(TPASS, "%llu kbytes allocated %s",
+			alloc_maxbytes / 1024, write_msg);
+
 	for (i = 0; i < pid_cntr; i++) {
 		TST_PROCESS_STATE_WAIT(pid_list[i], 'T');
 		kill(pid_list[i], SIGCONT);
-- 
2.20.1


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

* [LTP] [PATCH] mtest01: correct the ALLOC_THRESHOLD definition on s390x
  2019-11-28  4:55 [LTP] [PATCH] mtest01: correct the ALLOC_THRESHOLD definition on s390x Li Wang
@ 2019-11-29  9:55 ` Petr Vorel
  2019-11-29 12:16 ` Jan Stancek
  1 sibling, 0 replies; 4+ messages in thread
From: Petr Vorel @ 2019-11-29  9:55 UTC (permalink / raw)
  To: ltp

Hi Li,

> mtest01 hits a problem on s390x platform. The situation is that if children's
> memory allocating is ongoing and the test remaining time is in an emergency, the
> parent will break from the while loop and try to revoke children, obviously, it
> doesn't have enough time to wait for the children's status change to 'T'. Then it
> occurs timeout issue as below:

>   mtest01.c:134: INFO: Filling up 80% of free ram which is 5868864 kbytes
>   mtest01.c:149: INFO: ... child 38289 starting
>   mtest01.c:149: INFO: ... child 38288 starting
>   mtest01.c:208: WARN: the remaininig time is not enough for testing
>   mtest01.c:218: FAIL: kbytes allocated (and written to) less than expected 5868864
>   Test timeouted, sending SIGKILL!

> The immediate cause is the memory allocating is too slow to finish fleetly on such
> a small virtual s390x machine, because ALLOC_THRESHOLD does not take real effort.
> Here let's correct the allocating threshold definition to make sure each child
> allocates less memory.

> And, another fix for the fail handling. In case children are still on memory
> allocating, the remaining 15 seconds is not enough to wait for process status
> change. We kill them directly to avoid test timeout occurring.

> Signed-off-by: Li Wang <liwang@redhat.com>
> Cc: Rachel Sibley <rasibley@redhat.com>

Reviewed-by: Petr Vorel <pvorel@suse.cz>

Kind regards,
Petr

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

* [LTP] [PATCH] mtest01: correct the ALLOC_THRESHOLD definition on s390x
  2019-11-28  4:55 [LTP] [PATCH] mtest01: correct the ALLOC_THRESHOLD definition on s390x Li Wang
  2019-11-29  9:55 ` Petr Vorel
@ 2019-11-29 12:16 ` Jan Stancek
  2019-12-02  3:37   ` Li Wang
  1 sibling, 1 reply; 4+ messages in thread
From: Jan Stancek @ 2019-11-29 12:16 UTC (permalink / raw)
  To: ltp



----- Original Message -----
> mtest01 hits a problem on s390x platform. The situation is that if children's
> memory allocating is ongoing and the test remaining time is in an emergency,
> the
> parent will break from the while loop and try to revoke children, obviously,
> it
> doesn't have enough time to wait for the children's status change to 'T'.
> Then it
> occurs timeout issue as below:
> 
>   mtest01.c:134: INFO: Filling up 80% of free ram which is 5868864 kbytes
>   mtest01.c:149: INFO: ... child 38289 starting
>   mtest01.c:149: INFO: ... child 38288 starting
>   mtest01.c:208: WARN: the remaininig time is not enough for testing
>   mtest01.c:218: FAIL: kbytes allocated (and written to) less than expected
>   5868864
>   Test timeouted, sending SIGKILL!

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

I/O on that system looks painfully slow, if it can't fill ~5G of swap in 5 minutes.


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

* [LTP] [PATCH] mtest01: correct the ALLOC_THRESHOLD definition on s390x
  2019-11-29 12:16 ` Jan Stancek
@ 2019-12-02  3:37   ` Li Wang
  0 siblings, 0 replies; 4+ messages in thread
From: Li Wang @ 2019-12-02  3:37 UTC (permalink / raw)
  To: ltp

Pushed, thanks for the review.

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

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

end of thread, other threads:[~2019-12-02  3:37 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-11-28  4:55 [LTP] [PATCH] mtest01: correct the ALLOC_THRESHOLD definition on s390x Li Wang
2019-11-29  9:55 ` Petr Vorel
2019-11-29 12:16 ` Jan Stancek
2019-12-02  3:37   ` Li Wang

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.