From: Richard Palethorpe <rpalethorpe@suse.de>
To: ltp@lists.linux.it
Subject: [LTP] ee
Date: Wed, 30 Jun 2021 10:12:41 +0100 [thread overview]
Message-ID: <87r1gj3ed2.fsf@suse.de> (raw)
In-Reply-To: <YNwk9EwTtqAnRWH6@pevik>
Hello Petr,
Petr Vorel <pvorel@suse.cz> writes:
> Hi Richie,
>
> ...
>> > tst_fuzzy_sync01.c:224: TFAIL: acs:1 act:1 art:3 | =:3 -:2999996 +:1
>
>> It looks like the CI machines are too noisy/contended. The avg_dev is
>> very high. Probably we could relax the dev_ratio threshold to 0.2 or
>> 0.3. Although we would still get failures occassionally. As this is a
>> probabalistic test.
> Test is failing on my laptop, thus haven't enabled it in CI.
> But maybe it'll be working on it more reliably than my busy machine.
Is it really that busy? Perhaps we should increase the dev ratio
threshold. Clearly the deviations from contention are not enough to
reproduce the races, but are enough to prevent the radomization phase.
> But I'd prefer to wasting time with false positives, thus I guess we should
> enable only tests which are working reliably.
>
>> Could you change the script so that it passes so long as the test
>> returns TPASS or TFAIL?
> Well, accepting TFAIL sounds a bit strange to me :).
> Also next effort will be (at least for shell tests) to compare actual test
> output. Obviously that will not be straightforward for some tests, which aren't
> reproducible (avg = 11729ns could be matched by regex, but having more variants
> of results is kind of special case).
>
>> We don't want TBROK, TCONF or no result.
> FYI in my CI patchset is TCONF accepted. Motivation was to not require root for
> make test as some tests needed it. Thus TCONF will be a special case, then I
> guess we could add tst_fuzzy_sync01 accepting TFAIL as a special case.
At least if we run the tests and look for TPASS or TFAIL, we will catch
segfaults and similar.
Also, for fuzzy sync, returning TCONF would be a major error. It should
run on all systems.
>
> Kind regards,
> Petr
--
Thank you,
Richard.
next prev parent reply other threads:[~2021-06-30 9:12 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-29 20:22 [LTP] ee Petr Vorel
2021-06-29 20:59 ` [LTP] tst_fuzzy_sync01 sporadically fails Petr Vorel
2021-06-30 7:11 ` [LTP] ee Richard Palethorpe
2021-06-30 8:01 ` Petr Vorel
2021-06-30 9:12 ` Richard Palethorpe [this message]
2021-06-30 10:10 ` [LTP] tst_fuzzy_sync01 sporadically fails Petr Vorel
2021-06-30 12:05 ` Richard Palethorpe
2021-06-30 12:19 ` Petr Vorel
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87r1gj3ed2.fsf@suse.de \
--to=rpalethorpe@suse.de \
--cc=ltp@lists.linux.it \
/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