All of lore.kernel.org
 help / color / mirror / Atom feed
From: Keith Busch <kbusch@kernel.org>
To: Pavel Begunkov <asml.silence@gmail.com>
Cc: Andres Freund <andres@anarazel.de>,
	linux-block@vger.kernel.org, Jens Axboe <axboe@kernel.dk>
Subject: Re: hybrid polling on an nvme doesn't seem to work with iodepth > 1 on 5.10.0-rc5
Date: Fri, 11 Dec 2020 12:37:19 +0900	[thread overview]
Message-ID: <20201211033719.GA6414@redsun51.ssa.fujisawa.hgst.com> (raw)
In-Reply-To: <de0b46d2-d053-a7a8-23e7-fc954807c70d@gmail.com>

On Fri, Dec 11, 2020 at 01:44:38AM +0000, Pavel Begunkov wrote:
> On 11/12/2020 01:19, Andres Freund wrote:
> > On 2020-12-10 23:15:15 +0000, Pavel Begunkov wrote:
> >> On 10/12/2020 23:12, Pavel Begunkov wrote:
> >>> On 10/12/2020 20:51, Andres Freund wrote:
> >>>> Hi,
> >>>>
> >>>> When using hybrid polling (i.e echo 0 >
> >>>> /sys/block/nvme1n1/queue/io_poll_delay) I see stalls with fio when using
> >>>> an iodepth > 1. Sometimes fio hangs, other times the performance is
> >>>> really poor. I reproduced this with SSDs from different vendors.
> >>>
> >>> Can you get poll stats from debugfs while running with hybrid?
> >>> For both iodepth=1 and 32.
> >>
> >> Even better if for 32 you would show it in dynamic, i.e. cat it several
> >> times while running it.
> > 
> > Should read all email before responding...
> > 
> > This is a loop of grepping for 4k writes (only type I am doing), with 1s
> > interval. I started it before the fio run (after one with
> > iodepth=1). Once the iodepth 32 run finished (--timeout 10, but took
> > 42s0, I started a --iodepth 1 run.
> 
> Thanks! Your mean grows to more than 30s, so it'll sleep for 15s for each
> IO. Yep, the sleep time calculation is clearly broken for you.
> 
> In general the current hybrid polling doesn't work well with high QD,
> that's because statistics it based on are not very resilient to all sorts
> of problems. And it might be a problem I described long ago
> 
> https://www.spinics.net/lists/linux-block/msg61479.html
> https://lkml.org/lkml/2019/4/30/120

It sounds like the statistic is using the wrong criteria. It ought to
use the average time for the next available completion for any request
rather than the average latency of a specific IO. It might work at high
depth if the hybrid poll knew the hctx's depth when calculating the
sleep time, but that information doesn't appear to be readily available.

  reply	other threads:[~2020-12-11  3:38 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-10 20:51 hybrid polling on an nvme doesn't seem to work with iodepth > 1 on 5.10.0-rc5 Andres Freund
2020-12-10 23:12 ` Pavel Begunkov
2020-12-10 23:15   ` Pavel Begunkov
2020-12-11  1:19     ` Andres Freund
2020-12-11  1:44       ` Pavel Begunkov
2020-12-11  3:37         ` Keith Busch [this message]
2020-12-11 12:38           ` Pavel Begunkov
2020-12-13 18:19             ` Keith Busch
2020-12-14 17:58               ` Pavel Begunkov
2020-12-14 18:23                 ` Keith Busch
2020-12-14 19:01                   ` Pavel Begunkov
2020-12-16 22:22                     ` Keith Busch
2020-12-11  8:00         ` Andres Freund
2020-12-11  1:12   ` Andres Freund

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=20201211033719.GA6414@redsun51.ssa.fujisawa.hgst.com \
    --to=kbusch@kernel.org \
    --cc=andres@anarazel.de \
    --cc=asml.silence@gmail.com \
    --cc=axboe@kernel.dk \
    --cc=linux-block@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
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.