diff options
author | Stefan Liebler <stli@linux.ibm.com> | 2020-10-26 10:51:28 +0100 |
---|---|---|
committer | Stefan Liebler <stli@linux.ibm.com> | 2020-10-26 10:51:28 +0100 |
commit | 9a29f1a2ae3d4bb253ee368e0d71db0ca9494120 (patch) | |
tree | 8149a83d3d25474a3120cde25c1d0a82f4e64f62 /time/bug-asctime.c | |
parent | dac8713629c8736a60aebec2f01657e46baa4c73 (diff) | |
download | glibc-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