From: Jens Axboe <axboe@kernel.dk>
To: Paolo Valente <paolo.valente@linaro.org>,
linux-block <linux-block@vger.kernel.org>
Cc: Linus Walleij <linus.walleij@linaro.org>,
Mark Brown <broonie@kernel.org>,
Ulf Hansson <ulf.hansson@linaro.org>
Subject: Re: confusion about nr of pending I/O requests
Date: Tue, 18 Dec 2018 11:50:34 -0700 [thread overview]
Message-ID: <4db2cb0f-e500-44da-e85d-ed417b74dae5@kernel.dk> (raw)
In-Reply-To: <E0E52FD0-1020-4F5B-9AC8-F48BDFE142C0@linaro.org>
On 12/18/18 5:45 AM, Paolo Valente wrote:
> Hi Jens,
> sorry for the following silly question, but maybe you can solve very
> quickly a doubt for which I'd spend much more time investigating.
>
> While doing some tests with scsi_debug, I've just seen that (at least)
> with direct I/O, the maximum number of pending I/O requests (at least
> in the I/O schedulers) is equal, unexpectedly, to the queue depth of
> the drive and not to
> /sys/block/<dev>/queue/nr_requests
>
> For example, after:
>
> sudo modprobe scsi_debug max_queue=4
>
> and with fio executed as follows:
>
> job: (g=0): rw=read, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=libaio, iodepth=20
>
> I get this periodic trace, where four insertions are followed by four
> completions, and so on, till the end of the I/O. This trace is taken
> with none, but the result is the same with bfq.
>
> fio-20275 [001] d... 7560.655213: 8,48 I R 281088 + 8 [fio]
> fio-20275 [001] d... 7560.655288: 8,48 I R 281096 + 8 [fio]
> fio-20275 [001] d... 7560.655311: 8,48 I R 281104 + 8 [fio]
> fio-20275 [001] d... 7560.655331: 8,48 I R 281112 + 8 [fio]
> <idle>-0 [001] d.h. 7560.749868: 8,48 C R 281088 + 8 [0]
> <idle>-0 [001] dNh. 7560.749912: 8,48 C R 281096 + 8 [0]
> <idle>-0 [001] dNh. 7560.749928: 8,48 C R 281104 + 8 [0]
> <idle>-0 [001] dNh. 7560.749934: 8,48 C R 281112 + 8 [0]
> fio-20275 [001] d... 7560.750023: 8,48 I R 281120 + 8 [fio]
> fio-20275 [001] d... 7560.750196: 8,48 I R 281128 + 8 [fio]
> fio-20275 [001] d... 7560.750229: 8,48 I R 281136 + 8 [fio]
> fio-20275 [001] d... 7560.750250: 8,48 I R 281144 + 8 [fio]
> <idle>-0 [001] d.h. 7560.842510: 8,48 C R 281120 + 8 [0]
> <idle>-0 [001] dNh. 7560.842551: 8,48 C R 281128 + 8 [0]
> <idle>-0 [001] dNh. 7560.842556: 8,48 C R 281136 + 8 [0]
> <idle>-0 [001] dNh. 7560.842562: 8,48 C R 281144 + 8 [0]
>
> Shouldn't the total number of pending requests reach
> /sys/block/<dev>/queue/nr_requests ?
>
> The latter is of course equal to 8.
With a scheduler, the depth is what the scheduler provides. You cannot
exceed the hardware queue depth in any situation. You just have 8
requests available for scheduling, with a max of 4 being inflight on
the device side.
If both were 4, for instance, then you would have nothing to schedule
with, as all of them could reside on the hardware side. That's why
the scheduler defaults to twice the hardware queue depth.
--
Jens Axboe
next prev parent reply other threads:[~2018-12-18 18:50 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-12-18 12:45 confusion about nr of pending I/O requests Paolo Valente
2018-12-18 12:49 ` Paolo Valente
2018-12-18 18:50 ` Jens Axboe [this message]
2018-12-18 23:35 ` Paolo Valente
2018-12-19 3:45 ` Ming Lei
2018-12-19 6:17 ` Paolo Valente
2018-12-19 10:32 ` Ming Lei
2018-12-19 11:45 ` Paolo Valente
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=4db2cb0f-e500-44da-e85d-ed417b74dae5@kernel.dk \
--to=axboe@kernel.dk \
--cc=broonie@kernel.org \
--cc=linus.walleij@linaro.org \
--cc=linux-block@vger.kernel.org \
--cc=paolo.valente@linaro.org \
--cc=ulf.hansson@linaro.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
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