public inbox for ltp@lists.linux.it
 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox