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
next prev parent 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).