Speedup various nptl/tst-mutex5 tests.
Commit Message
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.
Comments
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.
@@ -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);