[PATCH] Speedup various nptl/tst-mutex5 tests.

[Stefan Liebler]

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