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-cancel20 and nptl/tst-cancel21 tests.

On 9/12/19 8:15 AM, Stefan Liebler wrote:
> Hi,
> 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".
> Bye,
> Stefan
> ChangeLog:
>     * 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?


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