about summary refs log tree commit diff
path: root/time/bug-asctime.c
diff options
context:
space:
mode:
authorStefan Liebler <stli@linux.ibm.com>2020-10-26 10:51:28 +0100
committerStefan Liebler <stli@linux.ibm.com>2020-10-26 10:51:28 +0100
commit9a29f1a2ae3d4bb253ee368e0d71db0ca9494120 (patch)
tree8149a83d3d25474a3120cde25c1d0a82f4e64f62 /time/bug-asctime.c
parentdac8713629c8736a60aebec2f01657e46baa4c73 (diff)
downloadglibc-9a29f1a2ae3d4bb253ee368e0d71db0ca9494120.tar.gz
glibc-9a29f1a2ae3d4bb253ee368e0d71db0ca9494120.tar.xz
glibc-9a29f1a2ae3d4bb253ee368e0d71db0ca9494120.zip
Remove timing related checks of time/tst-cpuclock1
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.

Afterwards the parent process sleeps with clock_nanosleep (child_clock, 0.1s):
diff = afterns - after
The test currently also allows 0.9 * 0.1s which would be an error.
Depending on the workload, the maximum limit can exceed the 1.2 * 0.1s.

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.

After discussion on the mailing list, we've decided to keep the functional
checks for the clock* functions and remove the timing related checks as those
are prone to false positives.

Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
Reviewed-by: Carlos O'Donell <carlos@redhat.com>
Diffstat (limited to 'time/bug-asctime.c')
0 files changed, 0 insertions, 0 deletions