All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jan Stancek <jstancek@redhat.com>
To: Petr Vorel <pvorel@suse.cz>
Cc: LTP List <ltp@lists.linux.it>
Subject: Re: [LTP] [PATCH] syscalls/fsync02: restore runtime to 5m
Date: Thu, 15 Sep 2022 08:39:53 +0200	[thread overview]
Message-ID: <CAASaF6xX=gBBjOVEnp6U4HpjfuzBVpbkyD1i0keW+iVjSCJZWg@mail.gmail.com> (raw)
In-Reply-To: <YyI+gHa7zCBIyjcg@pevik>

On Wed, Sep 14, 2022 at 10:50 PM Petr Vorel <pvorel@suse.cz> wrote:
>
> Hi Jan, Cyril,
>
> > Hi!
> > > Test allows up to 240 seconds for PASS result (depending if its VM or not),
> > > but on slower systems library now kills it after a minute. Restore
> > > runtime to 5 minutes.
>
> > Looking at the test itself it's a bit messed up too.
>
> > The test uses rand(); to initialize the buffer size but without
> > initializing the seed which is not random at all. It also uses number of
> > available disk blocks as a upper limit, which makes the test runtime
> > completely unpredictable.
>
> > I guess that it would make sense to randomize the buffer sizes but in
> > certain bounds to make the test more predictable and print the numbers
> > we are going to use too. Maybe run the test with a few different sizes
> > and time limits. Maybe the size of the buffers can be function of the
> > test runtime.
>
> > All in all I think that we should really rething what we are doing here
> > since the current code does not make that much sense to me.
>
> Jan, do you plan to do anything with the test before the release?

I put it at todo list, but haven't dived into it yet. For release, I'd
go with timelimit
extension as that can't cause any regressions.

>
> Kind regards,
> Petr
>
> > > Signed-off-by: Jan Stancek <jstancek@redhat.com>
> > > ---
> > >  testcases/kernel/syscalls/fsync/fsync02.c | 3 ++-
> > >  1 file changed, 2 insertions(+), 1 deletion(-)
>
> > > diff --git a/testcases/kernel/syscalls/fsync/fsync02.c b/testcases/kernel/syscalls/fsync/fsync02.c
> > > index e13ba89f1b63..55c7a71c1d65 100644
> > > --- a/testcases/kernel/syscalls/fsync/fsync02.c
> > > +++ b/testcases/kernel/syscalls/fsync/fsync02.c
> > > @@ -114,5 +114,6 @@ static struct tst_test test = {
> > >     .test_all = run,
> > >     .setup = setup,
> > >     .cleanup = cleanup,
> > > -   .needs_tmpdir = 1
> > > +   .needs_tmpdir = 1,
> > > +   .max_runtime = 300,
> > >  };
>


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

  reply	other threads:[~2022-09-15  6:40 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-20 10:43 [LTP] [PATCH] syscalls/fsync02: restore runtime to 5m Jan Stancek
2022-07-20 11:56 ` Cyril Hrubis
2022-09-14 20:50   ` Petr Vorel
2022-09-15  6:39     ` Jan Stancek [this message]
2022-09-15  8:04       ` Petr Vorel
2022-09-15 15:05       ` Cyril Hrubis
2022-09-16  9:03         ` Jan Stancek

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='CAASaF6xX=gBBjOVEnp6U4HpjfuzBVpbkyD1i0keW+iVjSCJZWg@mail.gmail.com' \
    --to=jstancek@redhat.com \
    --cc=ltp@lists.linux.it \
    --cc=pvorel@suse.cz \
    /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.