Flexible I/O Tester development
 help / color / mirror / Atom feed
From: Jens Axboe <axboe@kernel.dk>
To: Sitsofe Wheeler <sitsofe@gmail.com>
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 16:13:25 -0600	[thread overview]
Message-ID: <54288805.2020008@kernel.dk> (raw)
In-Reply-To: <20140928194419.GA24724@sucs.org>

[-- Attachment #1: Type: text/plain, Size: 2522 bytes --]

On 09/28/2014 01:44 PM, Sitsofe Wheeler wrote:
> On Sun, Sep 28, 2014 at 09:08:31AM -0600, Jens Axboe wrote:
>> On 2014-09-28 08:24, Jens Axboe wrote:
>>> On 2014-09-28 04:36, Sitsofe Wheeler wrote:
>>>> 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?
>>>
>>> I would agree on that, behavior for those cases _should_ be the same.
>>> Without the holed IO, it closes/reopens the file and repeats the 1M
>>> writes. With it, it does not. I will take a look.
>>
>> Does the attached fix it up?
> 
> The patch fixes
> fio --bs=4k --rw=write:4k --filename=/dev/shm/1M --name=go --io_limit=2M
> but not
> fio --bs=512k --rw=write --filename=/dev/shm/1M --name=go --number_io=4

number_ios=x is implemented as a cap, not a forced "must complete this
amount of ios to be done".

> or
> fio --bs=4k --rw=write --filename=/dev/shm/1M --name=go --zoneskip=4k --zonesize=4k --io_limit=2M

That one is a bit more tricky. Oh, try the attached (keep the previous
applied).

-- 
Jens Axboe


[-- Attachment #2: zone-skip.patch --]
[-- Type: text/x-patch, Size: 710 bytes --]

diff --git a/io_u.c b/io_u.c
index 8546899c03e7..02f600be3126 100644
--- a/io_u.c
+++ b/io_u.c
@@ -748,9 +751,13 @@ static int fill_io_u(struct thread_data *td, struct io_u *io_u)
 	 * See if it's time to switch to a new zone
 	 */
 	if (td->zone_bytes >= td->o.zone_size && td->o.zone_skip) {
+		struct fio_file *f = io_u->file;
+
 		td->zone_bytes = 0;
-		io_u->file->file_offset += td->o.zone_range + td->o.zone_skip;
-		io_u->file->last_pos = io_u->file->file_offset;
+		f->file_offset += td->o.zone_range + td->o.zone_skip;
+		if (f->file_offset >= f->real_file_size)
+			f->file_offset = f->real_file_size - f->file_offset;
+		f->last_pos = f->file_offset;
 		td->io_skip_bytes += td->o.zone_skip;
 	}
 

  reply	other threads:[~2014-09-28 22:13 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
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 [this message]
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=54288805.2020008@kernel.dk \
    --to=axboe@kernel.dk \
    --cc=andrey.v.kuzmin@gmail.com \
    --cc=fio@vger.kernel.org \
    --cc=ruby.wktk@gmail.com \
    --cc=sitsofe@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox