All of lore.kernel.org
 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 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.