All of lore.kernel.org
 help / color / mirror / Atom feed
From: Petr Vorel <pvorel@suse.cz>
To: Cyril Hrubis <chrubis@suse.cz>
Cc: Martin Doucha <martin.doucha@suse.com>, ltp@lists.linux.it
Subject: Re: [LTP] [PATCH 1/2] lib: multiply the timeout if detect slow kconfigsD
Date: Mon, 6 Jan 2025 13:52:55 +0100	[thread overview]
Message-ID: <20250106125255.GC302614@pevik> (raw)
In-Reply-To: <Z3vII4tENjV4G6GQ@yuki.lan>

> Hi!
> > I did a quick grep that some ltp-aiodio tests set it to 1800 sec, which
> > only 8/91 occupation in the LTP testcases/, I'm not sure if it's worth
> > adding a new field for those few stress tests.

> > And with the previous method, the multiple 4 max_runtime for 1800s
> > is 2hours per test up limit, I can't imagine how long we will get eventually
> > in the whole test time.

> > Maybe another way is to create a separate function in a header
> > like aio_common.h (or in high-level dir) for handling that significantly
> > larger runtime tests.

> > BTW, we have TST_UNLIMITED_RUNTIME choice or, invoke
> > tst_set_max_runtime() in somehow.

> I stil think that misusing max_runtime, which is supposed to be upper
> bound for the actual test runtime was a mistake.

Do you want to separate timeout for setup() and for actual test run?
Which one would be prolonged in case of "slow" kernels? (e.g. this patch).

Or you want to fix -iN?

Also for docs purposes it might be useful to list long running tests.
Fortunately there are just few tests which calls tst_set_max_runtime()
for dynamically set timeout.

> Maybe we should have called the max_runtime a timeout and add runtime
> for tests that needs it. That way we would have timeout compromising of
> two parts, one would be the 30s that is used for all tests and second
> part from the tst_test structure. And then the sum of these two would be
> multiplied by the timeout multipliers. Then we would have a runtime,
> which would be used only by tests that call tst_remaining_runtime().

> The overall test timeout would be then:

> (default_30s_timeout + tst_test->timeout) * TIMEOUT_MUL + tst_test->runtime * RUNTIME_MUL

> What do you think?

Timeout is for setup function, right? e.g. for ioctl_sg01? If yes, timeout is
too generic, IMHO many people will think that it's a general test timeout.
I would think about general name.

The above formula should be written in the docs in the separate description and
this section should be linked in TIMEOUT_MUL and RUNTIME_MUL description [1].

Maybe part of library README.md [2], which itself should be also moved to sphinx
docs.

Kind regards,
Petr

[1] https://linux-test-project.readthedocs.io/en/latest/users/setup_tests.html#library-environment-variables
[2] https://github.com/linux-test-project/ltp/blob/master/lib/README.md

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

  reply	other threads:[~2025-01-06 12:53 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-12-22  7:22 [LTP] [PATCH 1/2] lib: multiply the timeout if detect slow kconfigs Li Wang
2024-12-22  7:22 ` [LTP] [PATCH 2/2] starvation: skip test on slow kernel Li Wang
2025-01-02 12:56   ` Petr Vorel
2025-01-02 14:31     ` Petr Vorel
2025-01-03  7:53       ` Li Wang
2025-01-02 12:43 ` [LTP] [PATCH 1/2] lib: multiply the timeout if detect slow kconfigs Petr Vorel
2025-01-03  5:00   ` Li Wang
2025-01-03  7:06     ` Petr Vorel
2025-01-03  7:33       ` Petr Vorel
2025-01-03  7:58         ` Li Wang
2025-01-03 15:48     ` [LTP] [PATCH 1/2] lib: multiply the timeout if detect slow kconfigsD Cyril Hrubis
2025-01-04  3:38       ` Li Wang
2025-01-06  9:35         ` Petr Vorel
2025-01-06 12:10         ` Cyril Hrubis
2025-01-06 12:52           ` Petr Vorel [this message]
2025-01-06 13:39             ` Cyril Hrubis
2025-01-06 15:36               ` Petr Vorel
2025-01-06 16:19                 ` Cyril Hrubis
2025-01-07  5:37                   ` Li Wang
2025-01-07  6:28                     ` Li Wang
2025-01-07 12:42                       ` Cyril Hrubis
2025-01-07 16:49                         ` Petr Vorel
2025-01-08  1:47                           ` Li Wang
2025-01-08  2:51                             ` Li Wang
2025-01-06 16:03           ` Martin Doucha
2025-01-06 16:21             ` Cyril Hrubis
2025-01-06 16:49               ` Martin Doucha
2025-01-15 22:41 ` [LTP] [REGRESSION] Broken tests using tst_net.sh by 893ca0abe7 (was: [PATCH 1/2] lib: multiply the timeout if detect slow kconfigs) Petr Vorel
2025-01-16  6:54   ` Li Wang
2025-01-16  8:35     ` Petr Vorel
2025-01-16  8:38     ` Petr Vorel
2025-01-16 12:10       ` Li Wang
2025-01-16 12:13         ` Li Wang
2025-01-16 13:13         ` Petr Vorel
2025-01-16 12:56     ` Petr Vorel
2025-01-20  9:07     ` [LTP] [REGRESSION] pidns05 timeout " Petr Vorel
2025-01-20  9:11       ` Petr Vorel
2025-01-20 10:18         ` Li Wang
2025-01-20 12:29           ` Cyril Hrubis
2025-01-20 13:03             ` 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=20250106125255.GC302614@pevik \
    --to=pvorel@suse.cz \
    --cc=chrubis@suse.cz \
    --cc=ltp@lists.linux.it \
    --cc=martin.doucha@suse.com \
    /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.