fio.vger.kernel.org archive mirror
 help / color / mirror / Atom feed

From: Peter Veentjer <alarmnummer@gmail.com>
To: fio@vger.kernel.org
Subject: Fio sequential I/O request generation
Date: Thu, 18 May 2023 05:39:44 +0300	[thread overview]
Message-ID: <CAGuAWdAyy2yaM4mJ-CprFgg1JEOriom5Dv_xE8jH1qURdce9xA@mail.gmail.com> (raw)

Hi,

I'm working on io_uring integration for Java and using Fio to get a
performance baseline. The problem is that Fio is slower than my
benchmark and hence I do not have a proper baseline.

Part of my problem is that I don't understand how sequential I/O
generating works when the io_depth is larger than 1 (I'm testing with
64).

In the first version, I was iterating over the blocks in the file and
sequentially issuing the requests, and keeping the required number of
requests in flight. The problem is that this will lead to many
concurrent and consecutive blocks being scheduled and the Linux I/O
scheduler will merge many. iostat Confirmed that a huge percentage of
requests were merged.

Using iostat I have verified that Fio is not suffering from merged
read-request or write-requests, so I guess Fio is not using the above
approach.

Some other approaches I have tried.

1) Split the file into smaller sections and let each stride access a
portion of the file. E.g. io_level = 64 and a 64 MB file, each stride
gets a 1MB section of the file.

2) Each stride goes over the whole file but starts from a different
position. With 64 io_level, there are 64 different start offsets.

The performance I'm getting is still significantly higher than what
Fio measures so I'm sure that I'm doing something wrong (no apples vs
apples comparison). But the numbers my benchmark measures are
consistent with what iostat is reporting: the bandwidth and IOPS do
match.

I have included the Fio configuration for completeness:

fio --name=sometest --numjobs=1 --filesize=4M --time_based
--runtime=60s --ramp_time=2s --ioengine=io_uring  --direct=1
--verify=0 --bs=4k --iodepth=64 --rw=read --group_reporting=1
--cpus_allowed=1

I'm testing with Direct I/O and using a single thread that is pinned
to core 1 which does sequential reads and I want to keep 64 requests
in flight.

If someone could shine a light on how Fio generates requests for
sequential reads/writes.

Regards,

Peter.

next             reply	other threads:[~2023-05-18  2:39 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-18  2:39 Peter Veentjer [this message]
2023-06-16 21:14 ` Fio sequential I/O request generation Vincent Fu

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=CAGuAWdAyy2yaM4mJ-CprFgg1JEOriom5Dv_xE8jH1qURdce9xA@mail.gmail.com \
    --to=alarmnummer@gmail.com \
    --cc=fio@vger.kernel.org \
    /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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).