Message ID | 595be47d-f3b5-b4fb-06fb-334f002403b9@linux.ibm.com |
---|---|
State | New |
Headers | show |
Series | Speedup various nptl/tst-mutex5 tests. | expand |
On 9/12/19 8:16 AM, Stefan Liebler wrote: > Hi, > > each of these tests - tst-mutex5, tst-mutex5a, tst-mutexpi5 > and tst-mutexpi5a - runs for 6s. > > do_test_clock is called three times, which tries to lock the mutex > which times out after 2 seconds. > > This patch reduces the timeout to 0.3 seconds which leads to a > runtime of roughly 0.9s for one tst-mutex5... invocation. > As the nptl tests run in sequence, this patch saves roughly 20s of > runtime for "make check". > > Bye, > Stefan > > ChangeLog: > > * nptl/tst-mutex5.c (do_test_clock): Reduce timeout. Why is it safe to wait 0.3 seconds instead of 2 seconds? Is the timeout being used in place of synchronization elsewhere? We need a comment specifying if it's safe to lower the timeout even further.
On 9/12/19 4:15 PM, Carlos O'Donell wrote: > On 9/12/19 8:16 AM, Stefan Liebler wrote: >> Hi, >> >> each of these tests - tst-mutex5, tst-mutex5a, tst-mutexpi5 >> and tst-mutexpi5a - runs for 6s. >> >> do_test_clock is called three times, which tries to lock the mutex >> which times out after 2 seconds. >> >> This patch reduces the timeout to 0.3 seconds which leads to a >> runtime of roughly 0.9s for one tst-mutex5... invocation. >> As the nptl tests run in sequence, this patch saves roughly 20s of >> runtime for "make check". >> >> Bye, >> Stefan >> >> ChangeLog: >> >> * nptl/tst-mutex5.c (do_test_clock): Reduce timeout. > > Why is it safe to wait 0.3 seconds instead of 2 seconds? > > Is the timeout being used in place of synchronization elsewhere? > > We need a comment specifying if it's safe to lower the timeout > even further. > The mutex is locked a few lines above and is not used to synchronize elsewhere in the test. Instead the test checks that timedlock really delays when returning with ETIMEDOUT. So we need a measurable delay. A further check within tst-mutex5.c is using timedlock on a non-locked mutex in order to check that timedlock does not delay. There is the following comment: /* Check that timedlock didn't delay. We use a limit of 0.1 secs. */ As <0.1s is used as "not delayed" we should use a timeout of >=0.1s which is used as "delayed". To be a bit more safe, I propose 0.3s. But I don't think that we need the original 2s. What's your suggestion? What about this comment instead of "Wait xyz seconds": /* Check that timedlock delays for a measurable amount of time before returning with ETIMEDOUT. We use a delay of 0.3 secs. */ Bye, Stefan
commit 50f17c94072cb2a28290ec2d0502dcd9d925b61c Author: Stefan Liebler <stli@linux.ibm.com> Date: Wed Sep 11 10:53:48 2019 +0200 Speedup various nptl/tst-mutex5 tests. Each of these tests - tst-mutex5, tst-mutex5a, tst-mutexpi5 and tst-mutexpi5a - runs for 6s. do_test_clock is called three times, which tries to lock the mutex which times out after 2 seconds. This patch reduces the timeout to 0.3 seconds which leads to a runtime of roughly 0.9s for one tst-mutex5... invocation. As the nptl tests run in sequence, this patch saves roughly 20s of runtime for "make check". ChangeLog: * nptl/tst-mutex5.c (do_test_clock): Reduce timeout. diff --git a/nptl/tst-mutex5.c b/nptl/tst-mutex5.c index 1ecb483d4d..2f26637301 100644 --- a/nptl/tst-mutex5.c +++ b/nptl/tst-mutex5.c @@ -66,9 +66,9 @@ do_test_clock (clockid_t clockid, const char *fnname) if (pthread_mutex_trylock (&m) == 0) FAIL_EXIT1 ("mutex_trylock succeeded"); - /* Wait 2 seconds. */ + /* Wait 0.3 seconds. */ struct timespec ts_timeout = timespec_add (xclock_now (clockid_for_get), - make_timespec (2, 0)); + make_timespec (0, 300000000)); if (clockid == CLOCK_USE_TIMEDLOCK) TEST_COMPARE (pthread_mutex_timedlock (&m, &ts_timeout), ETIMEDOUT);