public inbox for linux-nvme@lists.infradead.org
 help / color / mirror / Atom feed
From: "Martin K. Petersen" <martin.petersen@oracle.com>
To: Keith Busch <kbusch@kernel.org>
Cc: sagi@grimberg.me, hch@lst.de, linux-nvme@lists.infradead.org
Subject: Re: [RFCv2] nvme-pci: adjust tagset parameters to match b/w
Date: Wed, 13 Oct 2021 12:04:49 -0400	[thread overview]
Message-ID: <yq1tuhlnd0c.fsf@ca-mkp.ca.oracle.com> (raw)
In-Reply-To: <20211013152136.1594409-1-kbusch@kernel.org> (Keith Busch's message of "Wed, 13 Oct 2021 08:21:36 -0700")


Keith,

> Instead of auto-adjusting the timeout to cope with the worst case
> scenario, this version adjusts the IO depth and max transfer size so
> that the worst case scenario fits within the driver's timeout
> tolerance.

I am totally in agreement with the concept of preventing mismatched
queue depth and I/O timeout.

I am a bit concerned wrt. PCIe bandwidth as a measure since that is not
necessarily representative of a drive's actual performance. But
obviously the queue feedback mechanism is still a bit of a can of
worms. For a sanity check, PCIe bandwidth is definitely acceptable.

> +	static const u32 min_bytes = 128 * 1024;
> +	static const u32 min_depth = 128;

Not sure about 128 as min depth. We have seen workloads where 32 or 64
performed best in practice although the drive internally had more
command slots available.

Also, haven't looked closely at your algorithm yet (impending meeting),
just want to point out that the default 30 seconds is a totally
unacceptable timeout for many of the things we care about. Our I/O
timeout is typically set to a couple of seconds. My hunch is that the
algorithm needs to take into account. In the past we have been bitten by
scaling algorithms that were essentially linear in nature and failed to
pick sensible defaults at very low input values or timeouts.

Anyway. Will have a closer look later.

-- 
Martin K. Petersen	Oracle Linux Engineering


  reply	other threads:[~2021-10-13 16:11 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-13 15:21 [RFCv2] nvme-pci: adjust tagset parameters to match b/w Keith Busch
2021-10-13 16:04 ` Martin K. Petersen [this message]
2021-10-13 16:49   ` Keith Busch

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=yq1tuhlnd0c.fsf@ca-mkp.ca.oracle.com \
    --to=martin.petersen@oracle.com \
    --cc=hch@lst.de \
    --cc=kbusch@kernel.org \
    --cc=linux-nvme@lists.infradead.org \
    --cc=sagi@grimberg.me \
    /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