public inbox for ltp@lists.linux.it
 help / color / mirror / Atom feed
From: Clemens Famulla-Conrad <cfamullaconrad@suse.com>
To: ltp@lists.linux.it
Subject: [LTP] [PATCH] memcg_stress_test.sh: Respect LTP_TIMEOUT_MUL set by user
Date: Thu, 12 Sep 2019 10:16:37 +0000	[thread overview]
Message-ID: <1568283397.3621.23.camel@suse.com> (raw)
In-Reply-To: <e07d08e2-df58-2114-0278-8f1e50f2ac3a@arm.com>

On Thu, 2019-09-12 at 10:55 +0100, Cristian Marussi wrote:
> Hi
> 
> > Hmm, what we want to do is:
> > 
> > If a testcase needs timeout value is larger than the default (300
> > sec), we
> > could only define a variable LTP_TIMEOUT_MUL_MIN in the test, then
> > the
> > _tst_setup_timer() will detect if LTP_TIMEOUT_MUL_MIN is valid and
> > reset
> > the minimum time for the test.
> > 
> > @Petr and @Cristian, If I misunderstand anything, please correct
> > me.
> 
> my understanding was that:
> 
> - we should already be able to set a non default per-test timeout
> using
>   the existing global LTP_TIMEOUT_MUL (and we are)
> 
> - in this test we hardcoded such LTP_TIMEOUT_MUL to 7 because is the
> minimum sane
>   value for this test (less than 7 and it fails 100%)
> 
> - we want to allow again the user to specify its own LTP_TIMEOUT_MUL
> if he wants
>   BUT also being able to enforce on a test by test basis a MINIMUM
> allowed value:
>   so we would define LTP_TIMEOUT_MUL_MIN=7 here, and then a user
> would be free to 
>   run LTP with a different global LTP_TIMEOUT_MUL but when running
> this test
>   
>   + if LTP_TIMEOUT_MUL < LTP_TIMEOUT_MUL_MIN ===> use local
> LTP_TIMEOUT_MUL_MIN
>   + if LTP_TIMEOUT_MUL >= LTP_TIMEOUT_MUL_MIN  ===> use global
> LTP_TIMEOUT_MUL
> 
> This way you don't break specific tests' needs while allowing the
> user to global reduce
> run-time....now basically the user cannot enforce a higher timeout on
> this test
> using the global LTP_TIMEOUT_MUL even if it should be allowed to
> since this wouldn't
> break the test.
> 
> ...unless I misunderstood too o_O :D

Thanks for explaining. That's how I understood the idea of
LTP_TIMEOUT_MUL_MIN, too.

But what I understood from current "c" approach is:
We have a fixed (minimal) timeout value, specified in (struct
tst_test*)->timeout, which can be adjusted by user with environment
variable TST_TIMEOUT_MUL.
This behavior is missing in shell.

And if we now introduce a LTP_TIMEOUT_MUL_MIN, it doesn't make much
sense, cause we have already a timeout min. So I think, we only need
something to specify the default minimum timeout in seconds for shell
(like we already do in c) and we are done.

Thanks
Clemens

  reply	other threads:[~2019-09-12 10:16 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-29 18:11 [LTP] [PATCH] memcg_stress_test.sh: Respect LTP_TIMEOUT_MUL set by user Petr Vorel
2019-08-30  2:39 ` Li Wang
2019-08-30  8:50   ` Petr Vorel
2019-08-30  9:07     ` Cristian Marussi
2019-08-30 10:46       ` Petr Vorel
2019-09-02  2:34         ` Li Wang
2019-09-12  9:04           ` Clemens Famulla-Conrad
2019-09-12  9:33             ` Cristian Marussi
2019-09-12  9:34             ` Li Wang
2019-09-12  9:51               ` Clemens Famulla-Conrad
2019-09-12  9:55               ` Cristian Marussi
2019-09-12 10:16                 ` Clemens Famulla-Conrad [this message]
2019-09-12 15:28                 ` Petr Vorel
2019-09-12 16:47                   ` Clemens Famulla-Conrad
2019-09-12 17:01                     ` 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=1568283397.3621.23.camel@suse.com \
    --to=cfamullaconrad@suse.com \
    --cc=ltp@lists.linux.it \
    /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