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;
}
next prev parent 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