All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sitsofe Wheeler <sitsofe@gmail.com>
To: Jens Axboe <axboe@kernel.dk>
Cc: Akira Hayakawa <ruby.wktk@gmail.com>,
	Andrey Kuzmin <andrey.v.kuzmin@gmail.com>,
	"fio@vger.kernel.org" <fio@vger.kernel.org>
Subject: Re: [Question] How to perform stride access?
Date: Sun, 28 Sep 2014 11:36:16 +0100	[thread overview]
Message-ID: <20140928103616.GA9991@sucs.org> (raw)
In-Reply-To: <5427716A.1080407@kernel.dk>

(Resending because first mail had an HTML part)

On 28 September 2014 03:24, Jens Axboe <axboe@kernel.dk> wrote:
>> On 24 September 2014 10:52, Sitsofe Wheeler <sitsofe@gmail.com> wrote:
>>>
>>> This looks like a bug. I can reproduce it with 2.1.11-11-gb7f5 too:
>>>
>>> dd if=/dev/zero of=/dev/shm/1M bs=1M count=1
>>> fio --bs=4k --rw=write:4k --filename=/dev/shm/1M --stonewall --name=1M
>>> --io_limit=1M  --name=2M --io_limit=2M
>>> [...]
>>>
>>> Run status group 0 (all jobs):
>>>    WRITE: io=512KB, aggrb=256000KB/s, minb=256000KB/s, maxb=256000KB/s,
>>> mint=2msec, maxt=2msec
>>>
>>> Run status group 1 (all jobs):
>>>    WRITE: io=512KB, aggrb=256000KB/s, minb=256000KB/s, maxb=256000KB/s,
>>> mint=2msec, maxt=2msec
>>>
>>> Why isn't io 1024KB for group 0? Additionally, shouldn't the total io
>>> written each group be different? Jens?
>
> You are doing a sequential workload, skipping 4k every time. First write
> will be to offset 0, next to 8KB, etc. Write 128 would be to 1040384,
which
> is 1MB - 8KB. Hence the next feasible offset after that would be 1MB,
which
> is end of the file. So how could it do more than 512KB of IO? That's 128 *
> 4KB.
>
> I didn't read the whole thread in detail, just looked at your last example
> here. And for that one, I don't see anything wrong.

I guess I would have thought io_limit always forced wraparound. For example:

# dd if=/dev/zero of=/dev/shm/1M bs=1M count=1
# fio --bs=4k --filename=/dev/shm/1M --name=go1 --rw=write
[...]
Run status group 0 (all jobs):
  WRITE: io=1024KB, aggrb=341333KB/s, minb=341333KB/s, maxb=341333KB/s,
mint=3msec, maxt=3msec
# fio --bs=4k --filename=/dev/shm/1M --name=go2 --io_limit=2M --rw=write
Run status group 0 (all jobs):
  WRITE: io=2048KB, aggrb=341333KB/s, minb=341333KB/s, maxb=341333KB/s,
mint=6msec, maxt=6msec
[...]
# fio --bs=4k --filename=/dev/shm/1M --name=go3 --io_limit=2M --rw=write:4k
[...]
  WRITE: io=512KB, aggrb=256000KB/s, minb=256000KB/s, maxb=256000KB/s,
mint=2msec, maxt=2msec
Run status group 0 (all jobs):
# fio --bs=4k --filename=/dev/shm/1M --name=go4 --io_limit=2M --rw=write:4k
[...]
Run status group 0 (all jobs):
  WRITE: io=512KB, aggrb=256000KB/s, minb=256000KB/s, maxb=256000KB/s,
mint=2msec, maxt=2msec

go2 is a plain sequential job that does twice as much I/O as go1. Given
that the size of the file being written to has not changed between the runs
one could guess that fio simply wrapped around and started from the first
offset (0) to write the second MB of data. Given this isn't it a fair
assumption that when doing a skipping workload if io_limit is used (as in
go4) and an offset beyond the end of the device is produced the same
wraparound behaviour as go2 should occur and the total io done should match
that specified in io_limit?

-- 
Sitsofe | http://sucs.org/~sits/


  parent reply	other threads:[~2014-09-28 10:36 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-23 13:47 [Question] How to perform stride access? Akira Hayakawa
2014-09-23 14:05 ` Andrey Kuzmin
2014-09-24  8:35   ` Akira Hayakawa
     [not found]     ` <CANvN+emPbk+MwwNoABs-rdWdJbn+JD+O0GVAGftR4w7mNVndcg@mail.gmail.com>
2014-09-24  9:28       ` Akira Hayakawa
2014-09-24  9:52     ` Sitsofe Wheeler
2014-09-24  9:58       ` Akira Hayakawa
2014-09-24 21:22       ` Sitsofe Wheeler
2014-09-28  2:24         ` Jens Axboe
2014-09-28 10:32           ` Sitsofe Wheeler
2014-09-28 10:36           ` Sitsofe Wheeler [this message]
2014-09-28 14:24             ` Jens Axboe
2014-09-28 15:08               ` Jens Axboe
2014-09-28 19:44                 ` Sitsofe Wheeler
2014-09-28 22:13                   ` Jens Axboe
2014-09-29  5:42                     ` Sitsofe Wheeler
2014-09-29  7:41                     ` Sitsofe Wheeler
2014-09-30  1:23                       ` Akira Hayakawa
2014-09-30  2:21                         ` Jens Axboe
2014-10-05  7:15                         ` Akira Hayakawa

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=20140928103616.GA9991@sucs.org \
    --to=sitsofe@gmail.com \
    --cc=andrey.v.kuzmin@gmail.com \
    --cc=axboe@kernel.dk \
    --cc=fio@vger.kernel.org \
    --cc=ruby.wktk@gmail.com \
    /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.