From: Keith Busch <kbusch@kernel.org>
To: "Michael Kelley (LINUX)" <mikelley@microsoft.com>
Cc: Daniel Gomez <dagmcr@gmail.com>, Christoph Hellwig <hch@lst.de>,
Sagi Grimberg <sagi@grimberg.me>,
Chaitanya Kulkarni <kch@nvidia.com>,
Gerd Bayer <gbayer@linux.ibm.com>,
"asahi@lists.linux.dev" <asahi@lists.linux.dev>,
"linux-nvme@lists.infradead.org" <linux-nvme@lists.infradead.org>
Subject: Re: max_hw_sectors error caused by recent NVMe driver commit
Date: Mon, 13 Feb 2023 09:57:45 -0700 [thread overview]
Message-ID: <Y+psCbPTfF9JkW2c@kbusch-mbp> (raw)
In-Reply-To: <BYAPR21MB16882541DC2DA7AB91E58A03D7DD9@BYAPR21MB1688.namprd21.prod.outlook.com>
On Mon, Feb 13, 2023 at 04:42:31PM +0000, Michael Kelley (LINUX) wrote:
> Ideally, to support
> 512 Kbyte transfers, you would want 129 segments (to allow for starting in
> the middle of a page as describe above). But the value of max_segments
> is limited by the NVME driver itself using the value of NVME_MAX_SEGS
> defined in drivers/nvme/host/pci.c. The value of 127 is chosen to make
> sure that the data structure containing the scatterlist fits in a single page.
> See nvme_pci_alloc_iod_mempool().
Should be 128 possible segements now in -next, but yeah, 129 would be ideal.
The limit confuses many because sometimes user space can sometimes get 512kib
IO to work and other times the same program fails, and all because of physical
memory continuity that user space isn't always aware of. A sure-fire way to
never hit that limit is to allocate hugepages.
next prev parent reply other threads:[~2023-02-13 16:57 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-11 5:33 max_hw_sectors error caused by recent NVMe driver commit Michael Kelley (LINUX)
2023-02-11 9:38 ` Daniel Gomez
2023-02-13 16:42 ` Michael Kelley (LINUX)
2023-02-13 16:57 ` Keith Busch [this message]
2023-02-17 13:28 ` Daniel Gomez
2023-02-17 16:05 ` Michael Kelley (LINUX)
2023-03-03 16:24 ` Daniel Gomez
2023-03-03 16:44 ` Keith Busch
2023-02-13 5:59 ` Christoph Hellwig
2023-02-13 6:41 ` Michael Kelley (LINUX)
2023-02-13 6:42 ` Christoph Hellwig
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=Y+psCbPTfF9JkW2c@kbusch-mbp \
--to=kbusch@kernel.org \
--cc=asahi@lists.linux.dev \
--cc=dagmcr@gmail.com \
--cc=gbayer@linux.ibm.com \
--cc=hch@lst.de \
--cc=kch@nvidia.com \
--cc=linux-nvme@lists.infradead.org \
--cc=mikelley@microsoft.com \
--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