From: Petr Vorel <pvorel@suse.cz>
To: ltp@lists.linux.it
Subject: [LTP] [PATCH] memcg_stress_test.sh: Respect LTP_TIMEOUT_MUL set by user
Date: Thu, 12 Sep 2019 17:28:20 +0200 [thread overview]
Message-ID: <20190912152820.GB1064@dell5510> (raw)
In-Reply-To: <e07d08e2-df58-2114-0278-8f1e50f2ac3a@arm.com>
Hi,
> > @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
LTP_TIMEOUT_MUL is only for user, LTP_TIMEOUT_MUL_MIN is only for library.
It's similar to way which is used in virt_lib.sh (VIRT_PERF_THRESHOLD_MIN).
See
https://patchwork.ozlabs.org/patch/1155460/
I'll probably sent this patch today although so you can base the work on it.
Is that ok?
Kind regards,
Petr
> 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
next prev parent reply other threads:[~2019-09-12 15:28 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
2019-09-12 15:28 ` Petr Vorel [this message]
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=20190912152820.GB1064@dell5510 \
--to=pvorel@suse.cz \
--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