From: Christoph Hellwig <hch@lst.de>
To: mhklinux@outlook.com
Cc: robin.murphy@arm.com, joro@8bytes.org, will@kernel.org,
jgross@suse.com, sstabellini@kernel.org,
oleksandr_tyshchenko@epam.com, hch@lst.de,
m.szyprowski@samsung.com, petr@tesarici.cz,
iommu@lists.linux.dev, linux-kernel@vger.kernel.org,
xen-devel@lists.xenproject.org
Subject: Re: [PATCH v2 1/1] swiotlb: Reduce swiotlb pool lookups
Date: Sat, 6 Jul 2024 07:50:19 +0200 [thread overview]
Message-ID: <20240706055019.GA13280@lst.de> (raw)
In-Reply-To: <20240701165746.1358-1-mhklinux@outlook.com>
Hi Michael,
I like the idea behind this, but can you respin it to avoid some of
the added code duplication. We have a lot of this pattern:
pool = swiotlb_find_pool(dev, paddr);
if (pool)
swiotlb_foo(dev, ...
duplicated in all three swiotlb users. If we rename the original
swiotlb_foo to __swiotlb_foo and add a little inline wrapper this is
de-duplicated and also avoids exposing swiotlb_find_pool to the
callers.
If we then stub out swiotlb_find_pool to return NULL for !CONFIG_SWIOTLB,
we also don't need extra stubs for all the __swiotlb_ helpers as the
compiler will eliminate the calls as dead code.
I might be missing something, but what is the reason for using the
lower-level __swiotlb_find_pool in swiotlb_map and xen_swiotlb_map_page?
I can't see a reason why the simple checks in swiotlb_find_pool itself
are either wrong or a performance problem there. Because if we don't
need these separate calls we can do away with __swiotlb_find_pool
for !CONFIG_SWIOTLB_DYNAMIC and simplify swiotlb_find_pool quite
a bit like this:
...
if (!mem)
return NULL;
if (IS_ENABLED(CONFIG_SWIOTLB_DYNAMIC)) {
smp_rmb();
if (!READ_ONCE(dev->dma_uses_io_tlb))
return NULL;
return __swiotlb_find_pool(dev, paddr);
}
if (paddr < mem->defpool.start || paddr >= mem->defpool.end)
return NULL;
return &dev->dma_io_tlb_mem->defpool;
While you're at it please fix the > 80 character lines as this patch
is adding plenty.
next prev parent reply other threads:[~2024-07-06 5:50 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-01 16:57 [PATCH v2 1/1] swiotlb: Reduce swiotlb pool lookups mhkelley58
2024-07-06 5:50 ` Christoph Hellwig [this message]
2024-07-07 2:11 ` Michael Kelley
2024-07-07 2:35 ` Michael Kelley
2024-07-07 6:36 ` Christoph Hellwig
2024-07-08 4:28 ` Petr Tesařík
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=20240706055019.GA13280@lst.de \
--to=hch@lst.de \
--cc=iommu@lists.linux.dev \
--cc=jgross@suse.com \
--cc=joro@8bytes.org \
--cc=linux-kernel@vger.kernel.org \
--cc=m.szyprowski@samsung.com \
--cc=mhklinux@outlook.com \
--cc=oleksandr_tyshchenko@epam.com \
--cc=petr@tesarici.cz \
--cc=robin.murphy@arm.com \
--cc=sstabellini@kernel.org \
--cc=will@kernel.org \
--cc=xen-devel@lists.xenproject.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.