All of lore.kernel.org
 help / color / mirror / Atom feed
From: Petr Vorel <pvorel@suse.cz>
To: Andrea Cervesato <andrea.cervesato@suse.com>
Cc: ltp@lists.linux.it
Subject: Re: [LTP] [PATCH v1] Rewrite msgstress testing suite
Date: Thu, 7 Mar 2024 23:07:57 +0100	[thread overview]
Message-ID: <20240307220757.GB211890@pevik> (raw)
In-Reply-To: <f61464e4-834f-4341-ab85-792765ddb9e5@suse.com>

> Hi!

> On 3/7/24 12:33, Cyril Hrubis wrote:
> > Hi!
> > First of all this patch removes all users of the libltpipc library but
> > keeps the library orphaned in libs/ leaving a dead code.
> This was done by purpose. I have track of dependences inside LTP and the
> idea is to remove it on a second moment. But I can send a following patch
> removing it already.

Actually, if it was done on purpose it is a bad approach. Splitting a cleanup
from a rewrite is asking to leave a dead code.

> > Secondly if you look at the libmsgctl.c you can actually see that the
> > reader and writer pair sends messages in a loop. This is imporatant
> > because without that the test can be hardly called a stress test. The
> > point is to start as much processes as possible that keep sending
> > messages around so that eventually we saturate the system. The new test
> > just sends a single message, which means that the children finish too
> > quickly and we never run more than a single digit of read/write pairs.
> > Given that we now have a runtime support in the test library we should
> > change this so that the reader/write paris continue to send messages
> > around until we are out of runtime. And the runtime should be at least a
> > minute.

> Actually this is a good idea, but test might send not enough messages if
> system is not responsive.
> I would keep the loop like we do now in this case, so we ensure a certain
> amount of stress, no matter the runtime.

I would agree with Cyril this is not much stressing (rewrite should not drop the
main purpose of the test).


...
> > > -	tst_resm(TPASS, "Test ran successfully!");
> > > +	tst_res(TPASS, "Received correct data");
> > This spams the test output with a few hundreds of lines of output, which
> > is known to choke test runners. For this case we should probably output
> > one single TPASS at the end of the test.

Can't we exit child non-zero on failure, store that via WIFEXITED() and print
TPASS only when none of the child runs failed?

> > Also this seems to be a common pattern, so we may as well add a function
> > into the test library that would produce TPASS unless we have seen a
> > FAIL/BROK/WARN. Or maybe just a function that would return sum of the
> > result counters so that we can do:

> > 	if (tst_get_res(TFAIL|TBROK|TWARN))
> > 		tst_res(TPASS, "All data were received correctly");

This looks to me better approach than expect that the default is to TPASS.

> Isn't it like this already?

No, it TBROK if you don't produce any of TPASS/TFAIL/TBROK/TCONF (TBROK can be
only in tst_brk()):

tst_test.c:1472: TBROK: Test 0 haven't reported results!

Kind regards,
Petr

> Regards,
> Andrea

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

  reply	other threads:[~2024-03-08  0:47 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-16 12:29 [LTP] [PATCH v1] Rewrite msgstress testing suite Andrea Cervesato
2024-03-07 11:33 ` Cyril Hrubis
2024-03-07 14:46   ` Andrea Cervesato via ltp
2024-03-07 22:07     ` Petr Vorel [this message]
2024-03-08 10:13     ` Cyril Hrubis

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=20240307220757.GB211890@pevik \
    --to=pvorel@suse.cz \
    --cc=andrea.cervesato@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 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.