All of lore.kernel.org
 help / color / mirror / Atom feed
From: Aneesh Kumar K.V <aneesh.kumar@kernel.org>
To: Robin Murphy <robin.murphy@arm.com>,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, iommu@lists.linux.dev
Cc: Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>,
	Marek Szyprowski <m.szyprowski@samsung.com>,
	suzuki.poulose@arm.com, steven.price@arm.com
Subject: Re: [PATCH] arm64: swiotlb: Don’t shrink default buffer when bounce is forced
Date: Wed, 21 Jan 2026 11:40:12 +0530	[thread overview]
Message-ID: <yq5ah5sfjy2j.fsf@kernel.org> (raw)
In-Reply-To: <028734f6-2a72-4509-81e0-7e69bda20253@arm.com>

Robin Murphy <robin.murphy@arm.com> writes:

> On 2026-01-20 7:01 am, Aneesh Kumar K.V (Arm) wrote:
>> arm64 reduces the default swiotlb size (for unaligned kmalloc()
>> bouncing) when it detects that no swiotlb bouncing is needed.
>> 
>> If swiotlb bouncing is explicitly forced via the command line
>> (swiotlb=force), this heuristic must not apply. Add a swiotlb helper to
>> query the forced-bounce state and use it to skip the resize when
>> bouncing is forced.
>
> This doesn't appear to be an arm64-specific concern though... Since 
> swiotlb_adjust_size() already prevents resizing if the user requests a 
> specific size on the command line, it seems logical enough to also not 
> reduce the size (but I guess still allow it to be enlarged) there if 
> force is requested.
>

Something like the below? I am wondering whether we are doing more than
what the function name suggests. Not allowing the size to be adjusted
when the kernel parameter specifies a swiotlb size seems fine. However,
I am not sure whether adding the force_bounce check is a good idea. I
only found RISC-V doing a similar size adjustment to arm64. Maybe we can
fix both architectures?

@@ -211,6 +211,8 @@ unsigned long swiotlb_size_or_default(void)
 
 void __init swiotlb_adjust_size(unsigned long size)
 {
+	unsigned long nslabs;
+
 	/*
 	 * If swiotlb parameter has not been specified, give a chance to
 	 * architectures such as those supporting memory encryption to
@@ -220,7 +222,13 @@ void __init swiotlb_adjust_size(unsigned long size)
 		return;
 
 	size = ALIGN(size, IO_TLB_SIZE);
-	default_nslabs = ALIGN(size >> IO_TLB_SHIFT, IO_TLB_SEGSIZE);
+	nslabs = ALIGN(size >> IO_TLB_SHIFT, IO_TLB_SEGSIZE);
+	/*
+	 * Don't allow to reduce size if we are forcing swiotlb bounce.
+	 */
+	if (swiotlb_force_bounce && nslabs < default_nslabs)
+		return;
+	default_nslabs = nslabs;
 	if (round_up_default_nslabs())
 		size = default_nslabs << IO_TLB_SHIFT;
 	pr_info("SWIOTLB bounce buffer size adjusted to %luMB", size >> 20);



  reply	other threads:[~2026-01-21  6:10 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-01-20  7:01 [PATCH] arm64: swiotlb: Don’t shrink default buffer when bounce is forced Aneesh Kumar K.V (Arm)
2026-01-20  9:25 ` Anshuman Khandual
2026-01-20 13:20 ` Robin Murphy
2026-01-21  6:10   ` Aneesh Kumar K.V [this message]
2026-02-04 18:52 ` Catalin Marinas
2026-02-06  6:11   ` Aneesh Kumar K.V
2026-03-04 10:00     ` Marek Szyprowski
2026-03-17  5:29       ` Aneesh Kumar K.V

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=yq5ah5sfjy2j.fsf@kernel.org \
    --to=aneesh.kumar@kernel.org \
    --cc=catalin.marinas@arm.com \
    --cc=iommu@lists.linux.dev \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=m.szyprowski@samsung.com \
    --cc=robin.murphy@arm.com \
    --cc=steven.price@arm.com \
    --cc=suzuki.poulose@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.