This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH] Speedup various nptl/tst-cancel20 and nptl/tst-cancel21 tests.
- From: Carlos O'Donell <carlos at redhat dot com>
- To: Stefan Liebler <stli at linux dot ibm dot com>, libc-alpha <libc-alpha at sourceware dot org>
- Date: Thu, 12 Sep 2019 10:07:34 -0400
- Subject: Re: [PATCH] Speedup various nptl/tst-cancel20 and nptl/tst-cancel21 tests.
- References: <email@example.com>
On 9/12/19 8:15 AM, Stefan Liebler wrote:
> each of thease tests - tst-cancel20, tst-cancelx20, tst-cancel21,
> tst-cancelx21 and tst-cancel21-static - runs for 8s.
> do_one_test is called 4 times. Either in do_one_test (tst-cancel20.c)
> or in tf (tst-cancel21.c) "sleep (1)" is called 2 times.
> This patch reduces the sleep time. Using usleep (5ms) leads to a
> runtime of one tst-cancel... invocation of roughly 40ms instead of 8s.
> As the nptl tests run in sequence, this patch saves roughly 39s of
> runtime for "make check".
> * nptl/tst-cancel20.c (do_one_test): Reduce sleep times.
> * nptl/tst-cancel21.c (tf): Likewise.
I see two possible solutions:
(a) Explain in detail why the sleep is needed, and why reducing
the sleep is safe.
(b) Remove the sleep and use proper barriers to provide the
synchronization the test is using sleep to accomplish.
Your current patch does (a) without explaining why it is safe
to reduce the sleep period, and that the test continues to test
what it was written to test.
Is it safe to reduce the sleep timing?
Why is it there?