All of lore.kernel.org
 help / color / mirror / Atom feed
From: Petr Vorel <pvorel@suse.cz>
To: ltp@lists.linux.it
Subject: [LTP] [PATCH 2/2] Avoid zero or negative int results in calculations
Date: Fri, 27 Mar 2020 16:23:47 +0100	[thread overview]
Message-ID: <20200327152347.GA8979@dell5510> (raw)
In-Reply-To: <98d9d28a-5da8-5c28-3b8f-0678a4988eda@suse.cz>

Hi Martin,

> Like I said in the previous e-mail, that slowdown is caused by the test
> intentionally randomizing the number of disk writes, not the patch. Run
> the test several times.

> > My concern is about brief explanation where/how is zero or negative result
> > appears. But maybe it's obvious and I just don't see it.

> Let me explain.

> > @@ -60,17 +61,15 @@ static void run(void) {

> >  	double time_delta;

> >  	long int random_number;



> > -	while (max_block <= data_blocks) {

> > -		random_number = rand();

> > -		max_block = random_number % max_blks;

> > -		data_blocks = random_number % 1000 + 1;

> > -	}

> > +	random_number = rand();

> > +	max_block = random_number % max_blks + 1;

> > +	data_blocks = random_number % max_block;


> This fixes a potential infinite loop if max_blks == 1000. This
> calculation is also the reason why the test has random run length.

Thanks for an explanation!

> >  	for (i = 1; i <= data_blocks; i++) {

> >  		offset = i * ((BLOCKSIZE * max_block) / data_blocks);

> > -		offset -= BUFSIZ;

> > +		offset -= BUF_SIZE;


> Here the old calculation could produce negative offset if
> BUFSIZ > BLOCKSIZE and (float)max_block/data_blocks is close to 1.
> BUFSIZ is defined in libc headers so the actual value can be different
> on different systems.
BTW BUFSIZ == BLOCKSIZE for glibc (BUFSIZ is 8192; long time ago was 1024. And
it's 1024 for musl and bionic).


Kind regards,
Petr

      reply	other threads:[~2020-03-27 15:23 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-24 13:38 [LTP] [PATCH 2/2] Avoid zero or negative int results in calculations Jozef Pupava
2020-03-26  8:45 ` Petr Vorel
2020-03-26 13:46   ` Cyril Hrubis
2020-03-26 20:32     ` Petr Vorel
2020-03-27  9:57       ` Petr Vorel
2020-03-27 10:15         ` Jozef Pupava
2020-03-27 10:17         ` Martin Doucha
2020-03-27 15:23           ` Petr Vorel [this message]

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=20200327152347.GA8979@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.