All of lore.kernel.org
 help / color / mirror / Atom feed
From: Clemens Famulla-Conrad <cfamullaconrad@suse.de>
To: ltp@lists.linux.it
Subject: [LTP] [PATCH] memcg_stress_test.sh: Respect LTP_TIMEOUT_MUL set by user
Date: Thu, 12 Sep 2019 11:04:33 +0200	[thread overview]
Message-ID: <1568279073.3621.12.camel@suse.de> (raw)
In-Reply-To: <CAEemH2ch1+asP7OKikqrM4Sea2f2xvVB4JPbUqDkm41cFJ+kdg@mail.gmail.com>

On Mon, 2019-09-02 at 10:34 +0800, Li Wang wrote:
> On Fri, Aug 30, 2019 at 6:46 PM Petr Vorel <pvorel@suse.cz> wrote:
> > 
> > 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 ?)
> 
> No, I guess the integer division in the shell/C is enough.
> 
> > 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).
> 
> +1 agree.

I have a general question. What do we try to get with
LTP_TIMEOUT_MUL_MIN? From my perspective, we try to set a minimum
timeout value. Isn't it the value (struct tst_test*)->timeout ?

I'm missing such configuration value for shell. Is there one?

Or do we need to increase timeout in smaller steps and that is why we
need this LTP_TIMEOUT_MUL_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).
> 
> Yes. But seems no need to involve a new field in struct tst_test,
> maybe we could complete that in the function tst_set_timeout(int
> timeout).
> 
> > 
> > > 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.
> 
> Agree.
> 
> -- 
> Regards,
> Li Wang
> 

  reply	other threads:[~2019-09-12  9:04 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 [this message]
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=1568279073.3621.12.camel@suse.de \
    --to=cfamullaconrad@suse.de \
    --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.