From: Cyril Hrubis <chrubis@suse.cz>
To: Li Wang <liwang@redhat.com>
Cc: LTP List <ltp@lists.linux.it>
Subject: Re: [LTP] [RFC] Reduce .runtime for Long-Running Tests ?
Date: Fri, 20 Jun 2025 11:04:17 +0200 [thread overview]
Message-ID: <aFUkEQXv7Wcy0lvv@yuki.lan> (raw)
In-Reply-To: <CAEemH2f8B5aJffcnbkYsr9j5KfZutgQkken8vbokNhsu19C8MA@mail.gmail.com>
Hi!
> After a round of experiments and internal discussions (thanks to
> Ian Wien for sharing his thoughts with me), we think that making
> LTP_RUNTIME_MUL support floating point numbers [0, 1] may
> a possible way to reduce the .runtime values set in tests.
>
> For example, setting LTP_RUNTIME_MUL to 0.1 can obviously
> reduce the test time of 600 seconds to 60 seconds.
>
> One may think that reducing the .runtime value in aproduction
> environment is potentially risky, and to some extent the answer
> is yes.
>
> But looking back, LTP is triggered very frequently in CI and various
> production flows, so to compensate for this loss, we can use floating
> point LTP_RUNTIME_MUL only in designated quick CI, instead of
> using it in daily tests. This will help cover more scenarios.
Having reduced runtime for CI makes sense, as you said you are making up
for the reduction by the number of testruns. It may not work well for
fuzzy sync though where we depend on having good enough sampling period.
Also limiting the smallest multiplier to be 0.1 or so does make sense. I
assume that if we set it to 0.01 or smaller most tests with runtime
woudn't even execute.
> From our CI report, use 0.1 in runtime_mul find a few failures in the round
> down problem with nice05.c (.runtime = 3), this is a defect of
> multply_runtime().
> Also, another preadv203 possible failure related this. But they are tiny
> issues. And the rest .runtime tests so far no obvious problem on that.
I guess that we need to make sure that the runtime stays positive. So
maybe we need something as:
runtime = MAX(2, tst_test->runtime * runtime_mul)
> So I would like to start the work from this point to reduce execution time.
Sounds good to me.
--
Cyril Hrubis
chrubis@suse.cz
--
Mailing list info: https://lists.linux.it/listinfo/ltp
next prev parent reply other threads:[~2025-06-20 9:03 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-27 11:00 [LTP] [RFC] Reduce .runtime for Long-Running Tests ? Li Wang via ltp
2025-05-27 11:10 ` Petr Vorel
2025-05-27 11:18 ` Li Wang via ltp
2025-05-27 11:11 ` Li Wang via ltp
2025-05-27 11:19 ` Cyril Hrubis
2025-05-27 11:28 ` Andrea Cervesato via ltp
2025-05-27 11:56 ` Cyril Hrubis
2025-05-28 13:35 ` Cyril Hrubis
2025-05-28 13:49 ` Martin Doucha
2025-05-29 1:53 ` Li Wang via ltp
2025-06-20 5:48 ` Li Wang via ltp
2025-06-20 9:04 ` Cyril Hrubis [this message]
2025-06-20 9:23 ` Li Wang via ltp
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=aFUkEQXv7Wcy0lvv@yuki.lan \
--to=chrubis@suse.cz \
--cc=liwang@redhat.com \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.