From: Cyril Hrubis <chrubis@suse.cz>
To: Richard Palethorpe <rpalethorpe@suse.de>
Cc: ltp@lists.linux.it
Subject: Re: [LTP] [PATCH 2/6] lib: Add .max_runtime and tst_remaining_runtime()
Date: Wed, 3 Nov 2021 12:09:00 +0100 [thread overview]
Message-ID: <YYJtzPQCAjvmgv05@yuki> (raw)
In-Reply-To: <87bl31o6ek.fsf@suse.de>
Hi!
> > This is another attempt of decoupling test runtime from timeouts.
>
> Do we have documentation explaining what runtimes and timeouts are?
>
> These two words are interchangeable.
Not yet I plan to rewrite documentation once things are finalized
enough.
> > Fundamentally there are two types of tests in LTP. First type are tests
> > that are rather quick (much less than a second) and can live with
> > whatever default timeout we set up. Second type of tests are tests that
> > run in a loop until timeout or a number of iterations is reached, these
> > are the tests that are going to be converted to the .max_runtime added
> > by this patch and followups.
>
> The code looks good, but this all feels quite hard to parse on a
> more abstract level. I think it is because you are trying to over
> generalise between different categories of test.
>
> So we have tests which run to completion as fast as they can. Then we
> have tests which iterate for some arbitrary time period (usually capped
> by some number of iterations as well, but it's not important).
>
> In the first case the concept of a target runtime makes no sense. So we
> end up with 'max runtime' which is the same type of thing as the timeout
> (although the value of timeout is greater).
>
> In the second case, where the test tries to execute for some length of
> time. Then the target runtime and timeout are really seperate things.
>
> I would suggest renaming 'max_runtime' to just 'runtime' and make it
> optional (defaults to 0). All tests which are of the second type can set
> .runtime = DEFAULT_RUNTIME (or whatever). If the test tries to use
> tst_remaining_runtime() without runtime being set, then an error is
> thrown.
That more of less what the patchset attempts to do. It hardcodes the
runtime as a number instead of having DEFAULT_RUNTIME constant though.
> If runtime is present then it can simply be added to the timeout to
> produce the "total timeout" (total_timeout = runtime + timeout).
I guess that would work reasonably well.
> This has the advantage of clearly showing in the meta data which tests
> are likely to run for some time. Also it means that the concept of
> 'runtime' doesn't change depending on the type of test. Finally we can
> set timeout very low by default.
>
> So when calculating how long a test executable may run for we have
>
> (runtime + timeout) * variants * iterations
>
> The wording is still not great. runtime is more like "deliberate
> runtime" and timeout is "maximal expected runtime after the deliberate
> runtime".
Sounds good. I will work on v2 that would include these changes.
--
Cyril Hrubis
chrubis@suse.cz
--
Mailing list info: https://lists.linux.it/listinfo/ltp
next prev parent reply other threads:[~2021-11-03 11:08 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-25 16:01 [LTP] [PATCH 0/6] Introduce a concept of test max_runtime Cyril Hrubis
2021-10-25 16:01 ` [LTP] [PATCH 1/6] lib: tst_test: Move timeout scaling out of fork_testrun() Cyril Hrubis
2021-10-25 16:01 ` [LTP] [PATCH 2/6] lib: Add .max_runtime and tst_remaining_runtime() Cyril Hrubis
2021-10-26 11:42 ` Jan Stancek
2021-10-26 12:49 ` Cyril Hrubis
2021-11-03 9:34 ` Richard Palethorpe
2021-11-03 11:09 ` Cyril Hrubis [this message]
2021-10-25 16:01 ` [LTP] [PATCH 3/6] mtest06/mmap3: Convert to tst_remaining_runtime() Cyril Hrubis
2021-10-25 16:01 ` [LTP] [PATCH 4/6] syscalls/gettimeofday02: " Cyril Hrubis
2021-10-25 16:01 ` [LTP] [PATCH 5/6] cve-2015-3290: convert tst_remining_runtime() Cyril Hrubis
2021-10-25 16:01 ` [LTP] [PATCH 6/6] lib: Add tst_set_runtime() & remove tst_set_timeout() Cyril Hrubis
2021-10-26 6:16 ` Li Wang
2021-10-26 7:14 ` Cyril Hrubis
2021-10-26 7:44 ` Li Wang
2021-10-26 7:56 ` Cyril Hrubis
2021-10-26 8:29 ` Li Wang
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=YYJtzPQCAjvmgv05@yuki \
--to=chrubis@suse.cz \
--cc=ltp@lists.linux.it \
--cc=rpalethorpe@suse.de \
/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