All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jens Axboe <axboe@kernel.dk>
To: Juergen Salk <juergen.salk@uni-ulm.de>
Cc: "fio@vger.kernel.org" <fio@vger.kernel.org>
Subject: Re: Amount of data read with mixed workload sequential/random with percentage_random set
Date: Wed, 23 Oct 2013 09:54:49 +0100	[thread overview]
Message-ID: <20131023085449.GV14598@kernel.dk> (raw)
In-Reply-To: <20131010054713.GA32463@highx.de>

On Thu, Oct 10 2013, Juergen Salk wrote:
> * Jens Axboe <axboe@kernel.dk> [130925 15:01]:
> 
> > >>> --- snip ---
> > >>> [global]
> > >>> ioengine=sync
> > >>> direct=0
> > >>> bssplit=19k/25:177k/15:350k/60
> > >>> size=100m
> > >>> numjobs=4
> > >>> directory=/tmp
> > >>>
> > >>> [work]
> > >>> rw=randread
> > >>> --- snip ---
> > >>>
> > >>> $ fio jobfile.fio >fio.out
> > >>> $ grep io= fio.out
> > >>>   read : io=199968KB, bw=4892.6KB/s, iops=27, runt= 40872msec
> > >>>   read : io=200062KB, bw=5083.5KB/s, iops=28, runt= 39359msec
> > >>>   read : io=200156KB, bw=4989.1KB/s, iops=27, runt= 40112msec
> > >>>   read : io=199940KB, bw=4492.4KB/s, iops=24, runt= 44507msec
> > >>>    READ: io=800126KB, aggrb=17977KB/s, minb=4492KB/s, maxb=5083KB/s, mint=39359msec, maxt=44507msec
> > >>>
> > >>> [...]
> > >>>
> > >>> I am probably missing something obvious, but why does the job file 
> > >>> above result in 200 MB read by every process?
> > >>
> > >> It should not, that's definitely a bug. I'm guessing it's triggered by
> > >> the strange block sizes being used. Can you see if adding:
> > >>
> > >> random_generator=lfsr
> > >>
> > >> helps?
> > > 
> > > Thanks for your response, Jens. Yes it does. It's a bit confusing
> > > though, as the man page says "LFSR only works with single block
> > > sizes, not with workloads that use multiple block sizes. If used
> > > with such a workload, fio may read or write some blocks multiple
> > > times." Shouldn't this be read as "Don't use LFSR with mixed
> > > block sizes."?
> > 
> > That is correct, my suspicion is just that the current logic around when
> > to decide to run another loop is wrong. Right now we just look to see if
> > the remainder is smaller than the max block size, but that doesn't mean
> > that we necessarily have that big of a free chunk available. I suspect
> > you are hitting this because of the odd block sizes.
> > 
> > > I am sorry to keep on harping on the matter, but I am planning to
> > > use fio for simulating file sizes where total runtime will
> > > become a serious issue. And these simulations will definitely
> > > involve strange mixed block sizes ...
> > 
> > No worries, it's definitely a bug. Checking for a fix right now...
> 
> Just out of curiosity: Is there any news on that issue? 

I got it mostly fixed, but it gets quite complicated. Traveling this
week, will hopefully have some time to wrap it up.

-- 
Jens Axboe


      reply	other threads:[~2013-10-23  8:55 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-09-18 14:58 Amount of data read with mixed workload sequential/random with percentage_random set Juergen Salk
2013-09-24 19:55 ` Juergen Salk
2013-09-25 20:05   ` Jens Axboe
2013-09-25 20:58     ` Juergen Salk
2013-09-25 21:01       ` Jens Axboe
2013-10-10  5:47         ` Juergen Salk
2013-10-23  8:54           ` Jens Axboe [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=20131023085449.GV14598@kernel.dk \
    --to=axboe@kernel.dk \
    --cc=fio@vger.kernel.org \
    --cc=juergen.salk@uni-ulm.de \
    /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.