This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

On 9/12/19 4:15 PM, Carlos O'Donell wrote:
On 9/12/19 8:16 AM, Stefan Liebler wrote:

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".



     * 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.  */


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]