From: Petr Vorel <pvorel@suse.cz>
To: Martin Doucha <mdoucha@suse.cz>
Cc: ltp@lists.linux.it
Subject: Re: [LTP] [PATCH V3] lib: multiply the max_runtime if detect slow kconfigs
Date: Thu, 19 Dec 2024 14:07:38 +0100 [thread overview]
Message-ID: <20241219130738.GA111004@pevik> (raw)
In-Reply-To: <b6da77f3-45d6-4eed-b2d3-90ad20c63e50@suse.cz>
> Hi!
> On 12. 12. 24 7:04, Li Wang wrote:
> > The method adjusts the max_runtime for test cases by multiplying
> > it by a factor (4x) if any slower kernel options are detected.
> > Debug kernel configurations (such as CONFIG_KASAN, CONFIG_PROVE_LOCKING, etc.)
> > are known to degrade performance, and this adjustment ensures
> > that tests do not fail prematurely due to timeouts.
> > As Cyril pointed out that a debug kernel will typically run
> > slower by a factor of N, and while determining the exact value
> > of N is challenging, so a reasonable upper bound is sufficient
> > for practical purposes.
> > Signed-off-by: Li Wang <liwang@redhat.com>
> > ---
> > include/tst_kconfig.h | 13 +++++++++++++
> > lib/tst_kconfig.c | 39 +++++++++++++++++++++++++++++++++++++++
> > lib/tst_test.c | 3 +++
> > 3 files changed, 55 insertions(+)
> > <snip>
> > diff --git a/lib/tst_test.c b/lib/tst_test.c
> > index 8db554dea..f4e667240 100644
> > --- a/lib/tst_test.c
> > +++ b/lib/tst_test.c
> > @@ -555,6 +555,9 @@ static int multiply_runtime(int max_runtime)
> > parse_mul(&runtime_mul, "LTP_RUNTIME_MUL", 0.0099, 100);
> > + if (tst_has_slow_kconfig())
> > + max_runtime *= 4;
> > +
> > return max_runtime * runtime_mul;
> > }
> We have plenty of tests which keep looping until they run out of runtime and
> then automatically stop. These tests are not at risk of timing out and this
> patch only makes them run 3 times longer than necessary.
> I'd recommend temporarily reverting this patch and adding it back with a new
> tst_test flag to identify tests which exit when runtime expires.
+1. Li, could you please do it?
Kind regards,
Petr
--
Mailing list info: https://lists.linux.it/listinfo/ltp
next prev parent reply other threads:[~2024-12-19 13:08 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-12 6:04 [LTP] [PATCH V3] lib: multiply the max_runtime if detect slow kconfigs Li Wang
2024-12-13 22:40 ` Petr Vorel
2024-12-16 9:37 ` Li Wang
2024-12-16 12:28 ` Petr Vorel
2024-12-17 2:40 ` Li Wang
2024-12-16 13:00 ` Cyril Hrubis
2024-12-16 17:29 ` Petr Vorel
2024-12-17 3:46 ` Li Wang
2024-12-18 3:23 ` Li Wang
2024-12-16 12:51 ` Cyril Hrubis
2024-12-19 12:53 ` Petr Vorel
2024-12-19 13:07 ` Li Wang
2024-12-19 12:57 ` Martin Doucha
2024-12-19 13:07 ` Petr Vorel [this message]
2024-12-19 13:12 ` Li Wang
2024-12-19 13:28 ` Petr Vorel
2024-12-19 13:29 ` Cyril Hrubis
2024-12-20 3:59 ` Li Wang
2024-12-20 7:19 ` Li Wang
2024-12-19 13:10 ` Cyril Hrubis
2024-12-19 13:14 ` Li Wang
2024-12-19 13:19 ` Cyril Hrubis
2024-12-19 13:22 ` Li Wang
2024-12-19 13:25 ` 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=20241219130738.GA111004@pevik \
--to=pvorel@suse.cz \
--cc=ltp@lists.linux.it \
--cc=mdoucha@suse.cz \
/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