unofficial mirror of libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: Florian Weimer <fweimer@redhat.com>
To: Carlos O'Donell <carlos@redhat.com>
Cc: Stefan Liebler <stli@linux.ibm.com>,
	 GNU C Library <libc-alpha@sourceware.org>
Subject: Re: How to handle long running tests in nptl.
Date: Fri, 13 Dec 2019 12:15:27 +0100	[thread overview]
Message-ID: <87wob079yo.fsf@oldenburg2.str.redhat.com> (raw)
In-Reply-To: <b4d07243-4042-d0de-58da-247dc341db99@redhat.com> (Carlos O'Donell's message of "Thu, 12 Sep 2019 10:02:15 -0400")

* Carlos O'Donell:

> On 9/12/19 9:21 AM, Stefan Liebler wrote:
>> Hi,
>> 
>> the nptl tests are currently running in sequence. Some of them are running very long:
>> -tst-cond16: 20s
>> -tst-cond17: 20s
>> -tst-cond18: 20s
>> -tst-rwlock-tryrdlock-stall: 20s
>> -tst-mutex10: 16s
>> -tst-rwlock20: 10s
>> -tst-rwlock-trywrlock-stall: 10s
>> -tst-rwlock-pwn: 10s
>> 
>> The listed tests are responsible for over two minutes of runtime of "make check". They all are running a test in a loop for a large amount of iterations or seconds in order to trigger e.g. a race condition.
>> 
>> How to handle those long running tests with respect of "make check" runtime?
>> - reduce runtime by reducing number of iterations or seconds
>> - move those tests to "make xcheck"
>> - reduce runtime while running "make check" and rerun with unchanged runtime in "make xcheck"
>> - change nothing
>> - other ideas?
>
> The use of 'make xcheck' is for tests that need specific persmissions
> to run, like root.

It's also used for tests that require many minutes to run or require
special firewall settings, e.g., resolv/tst-resolv-qtypes.

Unfortunately, we do not capture data of legitimate test failures, so
it's hard to tell how valuable such tests are.

Many of the timeout-heavy nptl tests do not actually need a quiet
system, though, so they could be moved to a separate subdirectory that
contains only such tests.  Or we could add some markup to the tests and
add a more intelligent test scheduler.

Thanks,
Florian


  reply	other threads:[~2019-12-13 11:16 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-12 13:21 How to handle long running tests in nptl Stefan Liebler
2019-09-12 14:02 ` Carlos O'Donell
2019-12-13 11:15   ` Florian Weimer [this message]
2019-12-13 20:39     ` Carlos O'Donell
2019-09-13 14:32 ` Cyril Hrubis

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=87wob079yo.fsf@oldenburg2.str.redhat.com \
    --to=fweimer@redhat.com \
    --cc=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).