[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