[PATCH] Speedup nptl/tst-rwlock19.
Stefan Liebler
stli@linux.ibm.com
Tue Sep 17 15:03:00 GMT 2019
On 9/12/19 4:14 PM, Carlos O'Donell wrote:
> On 9/12/19 8:16 AM, Stefan Liebler wrote:
>> Hi,
>>
>> the test creates 15 threads which are trying 5000x to pthread_rwlock_rdlock
>> a modified lock where the number of readers is set to max - 5.  If locked
>> successfully, it sleeps for 1ms.
>>
>> The test succeeds if the lock was rdlock'ed successfully for at least
>> one time and it has failed at least once with EAGAIN and the
>> number of readers needs to be max - 5 again after all threads have joined.
>>
>> The test is currently running for 5 seconds.  Thus this patch reduces
>> the READTRIES from 5000 to 100 and is increasing the DELAY from 1ms to 5ms.
>> Then the test runs for roughly 0.5 seconds.
>
> Why do we need to limit the retries?
>
> The point of the test is to run until we see a successful lock, and a failed
> lock with EAGAIN.
>
> It should be possible to make this test robust and so that when we run it
> on slower i686 it should jus run until it sees the events it needs to see,
> or fail from timeout (indicating a problem).
>
> I'm worried that by limiting the retires we'll see failures on slower or
> loaded hardware in the lab, and then we'll have to go back and bump up the
> retries again.
>
> The optimal test in my mind is:
>
> - Run forever.
> - Look for events of interest.
> - Exit success when those events are seen.
> - Fail if we timeout.
>
This sounds great.
I've adjusted the patch and READTRIES is now removed.
Bye
Stefan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 20190917_nptl_tstrwlock19.patch
Type: text/x-patch
Size: 2059 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/libc-alpha/attachments/20190917/20c5b97d/attachment.bin>
More information about the Libc-alpha
mailing list