unofficial mirror of libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: Carlos O'Donell <carlos@redhat.com>
To: Stefan Liebler <stli@linux.ibm.com>,
	GNU C Library <libc-alpha@sourceware.org>
Subject: Re: [PATCH] Speedup nptl/tst-rwlock19.
Date: Thu, 12 Sep 2019 10:14:44 -0400	[thread overview]
Message-ID: <d71d033e-6c9c-4ace-0ee3-ebf264211c2c@redhat.com> (raw)
In-Reply-To: <63377b64-9da9-0588-e3d5-92a4f1a1e6d0@linux.ibm.com>

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.

-- 
Cheers,
Carlos.

  reply	other threads:[~2019-09-12 14:14 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-12 12:16 [PATCH] Speedup nptl/tst-rwlock19 Stefan Liebler
2019-09-12 14:14 ` Carlos O'Donell [this message]
2019-09-17 15:03   ` Stefan Liebler

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/libc/involved.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=d71d033e-6c9c-4ace-0ee3-ebf264211c2c@redhat.com \
    --to=carlos@redhat.com \
    --cc=libc-alpha@sourceware.org \
    --cc=stli@linux.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).