From: Christoph Hellwig <hch@lst.de>
To: John Garry <john.g.garry@oracle.com>
Cc: Christoph Hellwig <hch@lst.de>,
Marek Szyprowski <m.szyprowski@samsung.com>,
Robin Murphy <robin.murphy@arm.com>,
Joerg Roedel <joro@8bytes.org>, Will Deacon <will@kernel.org>,
iommu@lists.linux.dev, linux-nvme@lists.infradead.org
Subject: Re: dma_opt_mapping_size returns way too low sizes when using IOMMU
Date: Wed, 19 Aug 2026 10:51:37 +0200 [thread overview]
Message-ID: <20260819085137.GA8550@lst.de> (raw)
In-Reply-To: <8b7e86a7-6cb1-4007-bd99-1c4be8e6828e@oracle.com>
On Mon, Aug 17, 2026 at 11:11:43AM +0100, John Garry wrote:
>> At least on the four different nvme devices I tested, the larger I/O
>> sizes made up for this. But maybe the details depend on other
>> factors as well.
> Are you saying that you tried increasing IOVA_RANGE_CACHE_MAX_SIZE and got
> better performance?
No, just disabling this hint.
> As I remember, I was told that the value of 6 for IOVA_RANGE_CACHE_MAX_SIZE
> was originally chosen from the value then in max page order, i.e. the idea
> was that we should not be getting streaming IOs larger than that value. But
> in looking at lore, 8 was very originally proposed, but I can't see any
> discussion on why that changed or any relation to page max order.
But that's a bit weird. A bio already does up to 256 entries, and a
request can have many more.
prev parent reply other threads:[~2026-08-19 8:51 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-17 8:36 dma_opt_mapping_size returns way too low sizes when using IOMMU Christoph Hellwig
2026-08-17 9:12 ` John Garry
2026-08-17 9:18 ` Christoph Hellwig
2026-08-17 10:11 ` John Garry
2026-08-17 17:04 ` Robin Murphy
2026-08-19 8:57 ` Christoph Hellwig
2026-08-19 8:51 ` Christoph Hellwig [this message]
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=20260819085137.GA8550@lst.de \
--to=hch@lst.de \
--cc=iommu@lists.linux.dev \
--cc=john.g.garry@oracle.com \
--cc=joro@8bytes.org \
--cc=linux-nvme@lists.infradead.org \
--cc=m.szyprowski@samsung.com \
--cc=robin.murphy@arm.com \
--cc=will@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.