public inbox for ltp@lists.linux.it
 help / color / mirror / Atom feed
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

  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