public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: Stefan Liebler <stli@linux.ibm.com>
To: libc-alpha@sourceware.org
Cc: lamm@linux.ibm.com, Stefan Liebler <stli@linux.ibm.com>
Subject: [PATCH] Loosen the limits of time/tst-cpuclock1.
Date: Fri, 28 Aug 2020 10:58:52 +0200	[thread overview]
Message-ID: <20200828085852.1861153-1-stli@linux.ibm.com> (raw)

Starting with the commit 04deeaa9ea74b0679dfc9d9155a37b6425f19a9f
"Fix time/tst-cpuclock1 intermitent failures" (2020-07-11),
this test fails quite often on s390x/s390 with one/multiple of those:
"before - after" / "nanosleep time" / "dead - after" ourside reasonable range.

On a zVM/kvm guest the CPUs are shared between multiple guests.
And even on the lpar (kvm host) the CPUs are usually shared between multiple lpars.
The defined CPUs for a lpar/zVM-system could also have lower weights compared
to other lpars which let the steal time further grow.

Usually I build (-j$(nproc)) and test (PARALLELMFLAGS="-j$(nproc)") glibc multiple
times, e.g. with different GCCs, on various lpars or zVM guests at the same time.
During this time, I've run the test for 13500 times and obvserved the following fails:
~600x "before - after"
~60x "nanosleep time"
~70x "dead - after"

I've also observed a lot of "before - after" fails on a intel kvm-guest while
building/testing glibc on it.

The mentioned commit has tighten the limits of valid tv_nsec ranges:
"before - after" (expected: 500000000):
- 100000000 ... 600000000
+ 450000000 ... 550000000

"nanosleep time" (expected: 100000000):
- 100000000 ... 200000000
+ 090000000 ... 120000000

"dead - after" (expected: 100000000):
-           ... 200000000
+ 090000000 ... 120000000

The test itself forks a child process which chew_cpu (user- and kernel-space).
The parent process sleeps with nanosleep(0.5s) and measures the child_clock time:
diff = after - before"
With much workload on the machine, the child won't make much progess
and it can fall much beyond the minimum limit. Thus I've set this limit to 0.45%.
Even with this limit, the test fails for 11..90 times. If set to 0.30% it fails
only 1..8 times.
Does this check makes sense at all?

Afterwards the parent process sleeps  with clock_nanosleep (child_clock, 0.1s):
diff = afterns - after
The test currently also allows 0.9 * 0.1s.  Shouldn't we test the hard limit of
1.0 * 0.1s as minimum limit?
Depending on the workload, the maximum limit can exceed the 1.2 * 0.1s. Therefore
I've set the upper limit to 1.35.

For "dead - after", the parent process kills the child process and waits long
enough to let the child finish dying. Then it gets the time of the child:
diff = dead - after
Note that diff also contains the time for the previous clock_nanosleep.
Thus you'll often see both fails at the same time. I've set the upper limit
to 1.4.
---
 time/tst-cpuclock1.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/time/tst-cpuclock1.c b/time/tst-cpuclock1.c
index 1ac611a92b..52a3485145 100644
--- a/time/tst-cpuclock1.c
+++ b/time/tst-cpuclock1.c
@@ -161,7 +161,7 @@ do_test (void)
      percentile of values and use those values for our testing allowed range.  */
   struct timespec diff = timespec_sub (support_timespec_normalize (after),
 				       support_timespec_normalize (before));
-  if (!support_timespec_check_in_range (sleeptime, diff, .9,  1.1))
+  if (!support_timespec_check_in_range (sleeptime, diff, .45,  1.1))
     {
       printf ("before - after %ju.%.9ju outside reasonable range\n",
 	      (uintmax_t) diff.tv_sec, (uintmax_t) diff.tv_nsec);
@@ -197,7 +197,7 @@ do_test (void)
            allowed range.  */
 	  diff = timespec_sub (support_timespec_normalize (afterns),
 			       support_timespec_normalize (after));
-	  if (!support_timespec_check_in_range (sleeptime, diff, .9, 1.2))
+	  if (!support_timespec_check_in_range (sleeptime, diff, 1.0, 1.35))
 	    {
 	      printf ("nanosleep time %ju.%.9ju outside reasonable range\n",
 		      (uintmax_t) diff.tv_sec, (uintmax_t) diff.tv_nsec);
@@ -240,7 +240,7 @@ do_test (void)
   diff = timespec_sub (support_timespec_normalize (dead),
 		       support_timespec_normalize (after));
   sleeptime.tv_nsec = 100000000;
-  if (!support_timespec_check_in_range (sleeptime, diff, .9, 1.2))
+  if (!support_timespec_check_in_range (sleeptime, diff, 1.0, 1.4))
     {
       printf ("dead - after %ju.%.9ju outside reasonable range\n",
 	      (uintmax_t) diff.tv_sec, (uintmax_t) diff.tv_nsec);
-- 
2.25.3


             reply	other threads:[~2020-08-28  8:59 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-28  8:58 Stefan Liebler [this message]
2020-08-28 12:29 ` Florian Weimer
2020-08-31 12:57   ` Lucas A. M. Magalhaes
2020-08-31 12:59     ` Florian Weimer
2020-09-02 16:10       ` Stefan Liebler
2020-09-21 11:28         ` Florian Weimer
2020-09-29 13:53           ` Lucas A. M. Magalhaes
2020-09-29 14:01             ` Adhemerval Zanella
2020-09-29 17:22               ` Carlos O'Donell
2020-09-30 11:48                 ` Adhemerval Zanella
2020-10-19 14:48                   ` Stefan Liebler

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200828085852.1861153-1-stli@linux.ibm.com \
    --to=stli@linux.ibm.com \
    --cc=lamm@linux.ibm.com \
    --cc=libc-alpha@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).