From: Christoph Hellwig <hch@infradead.org>
To: Tianyu Lan <ltykernel@gmail.com>
Cc: corbet@lwn.net, hch@infradead.org, m.szyprowski@samsung.com,
robin.murphy@arm.com, paulmck@kernel.org, bp@suse.de,
akpm@linux-foundation.org, keescook@chromium.org,
pmladek@suse.com, rdunlap@infradead.org,
damien.lemoal@opensource.wdc.com, michael.h.kelley@microsoft.com,
kys@microsoft.com, Tianyu Lan <Tianyu.Lan@microsoft.com>,
iommu@lists.linux-foundation.org, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org, vkuznets@redhat.com,
wei.liu@kernel.org, parri.andrea@gmail.com,
thomas.lendacky@amd.com, linux-hyperv@vger.kernel.org,
kirill.shutemov@intel.com, andi.kleen@intel.com,
Andi Kleen <ak@linux.intel.com>
Subject: Re: [PATCH V3] swiotlb: Split up single swiotlb lock
Date: Thu, 7 Jul 2022 10:07:00 -0700 [thread overview]
Message-ID: <YscStPk/IXW9PPmh@infradead.org> (raw)
In-Reply-To: <20220707082436.447984-1-ltykernel@gmail.com>
On Thu, Jul 07, 2022 at 04:24:36AM -0400, Tianyu Lan wrote:
> From: Tianyu Lan <Tianyu.Lan@microsoft.com>
>
> Traditionally swiotlb was not performance critical because it was only
> used for slow devices. But in some setups, like TDX/SEV confidential
> guests, all IO has to go through swiotlb. Currently swiotlb only has a
> single lock. Under high IO load with multiple CPUs this can lead to
> significat lock contention on the swiotlb lock.
>
> This patch splits the swiotlb bounce buffer pool into individual areas
> which have their own lock. Each CPU tries to allocate in its own area
> first. Only if that fails does it search other areas. On freeing the
> allocation is freed into the area where the memory was originally
> allocated from.
>
> Area number can be set via swiotlb kernel parameter and is default
> to be possible cpu number. If possible cpu number is not power of
> 2, area number will be round up to the next power of 2.
>
> This idea from Andi Kleen patch(https://github.com/intel/tdx/commit/
> 4529b5784c141782c72ec9bd9a92df2b68cb7d45).
Thanks, this looks much better. I think there is a small problem
with how default_nareas is set - we need to use 0 as the default
so that an explicit command line value of 1 works. Als have you
checked the interaction with swiotlb_adjust_size in detail?
diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c
index 5536d2cd69d30..85b1c29dd0eb8 100644
--- a/kernel/dma/swiotlb.c
+++ b/kernel/dma/swiotlb.c
@@ -70,7 +70,7 @@ struct io_tlb_mem io_tlb_default_mem;
phys_addr_t swiotlb_unencrypted_base;
static unsigned long default_nslabs = IO_TLB_DEFAULT_SIZE >> IO_TLB_SHIFT;
-static unsigned long default_nareas = 1;
+static unsigned long default_nareas;
/**
* struct io_tlb_area - IO TLB memory area descriptor
@@ -90,7 +90,10 @@ struct io_tlb_area {
static void swiotlb_adjust_nareas(unsigned int nareas)
{
- if (!is_power_of_2(nareas))
+ if (default_nareas)
+ return;
+
+ if (nareas > 1 && !is_power_of_2(nareas))
nareas = roundup_pow_of_two(nareas);
default_nareas = nareas;
@@ -338,8 +341,7 @@ void __init swiotlb_init_remap(bool addressing_limit, unsigned int flags,
panic("%s: Failed to allocate %zu bytes align=0x%lx\n",
__func__, alloc_size, PAGE_SIZE);
- if (default_nareas == 1)
- swiotlb_adjust_nareas(num_possible_cpus());
+ swiotlb_adjust_nareas(num_possible_cpus());
mem->areas = memblock_alloc(sizeof(struct io_tlb_area) *
default_nareas, SMP_CACHE_BYTES);
@@ -410,8 +412,7 @@ int swiotlb_init_late(size_t size, gfp_t gfp_mask,
(PAGE_SIZE << order) >> 20);
}
- if (default_nareas == 1)
- swiotlb_adjust_nareas(num_possible_cpus());
+ swiotlb_adjust_nareas(num_possible_cpus());
area_order = get_order(array_size(sizeof(*mem->areas),
default_nareas));
next prev parent reply other threads:[~2022-07-07 17:07 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-07 8:24 [PATCH V3] swiotlb: Split up single swiotlb lock Tianyu Lan
2022-07-07 17:07 ` Christoph Hellwig [this message]
2022-07-08 16:21 ` Tianyu Lan
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=YscStPk/IXW9PPmh@infradead.org \
--to=hch@infradead.org \
--cc=Tianyu.Lan@microsoft.com \
--cc=ak@linux.intel.com \
--cc=akpm@linux-foundation.org \
--cc=andi.kleen@intel.com \
--cc=bp@suse.de \
--cc=corbet@lwn.net \
--cc=damien.lemoal@opensource.wdc.com \
--cc=iommu@lists.linux-foundation.org \
--cc=keescook@chromium.org \
--cc=kirill.shutemov@intel.com \
--cc=kys@microsoft.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-hyperv@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=ltykernel@gmail.com \
--cc=m.szyprowski@samsung.com \
--cc=michael.h.kelley@microsoft.com \
--cc=parri.andrea@gmail.com \
--cc=paulmck@kernel.org \
--cc=pmladek@suse.com \
--cc=rdunlap@infradead.org \
--cc=robin.murphy@arm.com \
--cc=thomas.lendacky@amd.com \
--cc=vkuznets@redhat.com \
--cc=wei.liu@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).