All of lore.kernel.org
 help / color / mirror / Atom feed
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: Fri, 30 Aug 2019 12:46:10 +0200	[thread overview]
Message-ID: <20190830104609.GA9330@dell5510> (raw)
In-Reply-To: <9e518589-9c98-1513-2c19-bae0268b8a81@arm.com>

Hi Cristian,

> On 30/08/2019 09:50, Petr Vorel wrote:
> > Hi Li,

> > Good point. Something like this could do it:
> > -LTP_TIMEOUT_MUL=7
> > +min_timeout=7
> > +[ -z "$LTP_TIMEOUT_MUL" -o "$LTP_TIMEOUT_MUL" -lt $min_timeout ] && LTP_TIMEOUT_MUL=$min_timeout

> > Unless we test only integers:
> > +[ is_int "$LTP_TIMEOUT_MUL" -o "$LTP_TIMEOUT_MUL" -lt $min_timeout ] && LTP_TIMEOUT_MUL=$min_timeout


> I would certainly introduce a check on the minimum allowed test-timeout and just stick to integers.
> (is it really needed to worry for float multipliers ?)
Not sure, but it'd be good to have it same for C and for shell. Otherwise
working variable for C would fail on shell.

> I also wonder if it is worth somehow put this minimum-enforce mechanism inside the framework itself
> instead that hardcoding it in this specific test (unless you already mean to do it this way...
> and I misunderstood)
Yes, I was thinking about it as well.
LTP_TIMEOUT_MUL should be reserved for users, tests should use LTP_TIMEOUT_MUL_MIN,
check for LTP_TIMEOUT_MUL being higher than LTP_TIMEOUT_MUL_MIN would be in
_tst_setup_timer(). Similar mechanism I introduced in 9d6a960d9 (VIRT_PERF_THRESHOLD_MIN).

I wonder if it'd be useful to have some functionality in C (ltp_timeout_mul_min
as a struct tst_test, default 1).

> So that, roughly, in the test

> LTP_TIMEOUT_MUL_MIN=7
> LTP_TIMEOUT_MUL=${LTP_TIMEOUT_MUL:-7}

> and somewhere in framework test initialization you enforce it (maybe with a warning for the user when overriding its setup)

> [ -z "$LTP_TIMEOUT_MUL" -o "$LTP_TIMEOUT_MUL" -lt $LTP_TIMEOUT_MUL_MIN ] && LTP_TIMEOUT_MUL=$LTP_TIMEOUT_MUL_MIN
+1. Feel free to send a patch.

> (but my LTP framework memories are a bit blurred now...so feel free to ignore if it is not feasible or practical)

> Thanks

> Cristian

Kind regards,
Petr

  reply	other threads:[~2019-08-30 10:46 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 [this message]
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
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=20190830104609.GA9330@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 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.