mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Bibek Kumar Patro <bibek.patro@oss.qualcomm.com>
To: Michael Kelley <mhklinux@outlook.com>,
	Marek Szyprowski <m.szyprowski@samsung.com>,
	Robin Murphy <robin.murphy@arm.com>
Cc: "iommu@lists.linux.dev" <iommu@lists.linux.dev>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Jagadeesh Pagadala <jpagadal@qti.qualcomm.com>
Subject: Re: [PATCH] swiotlb: introduce Kconfig option for compile-time default pool size
Date: Thu, 2 Jul 2026 19:14:37 +0530	[thread overview]
Message-ID: <70dd2528-e0b3-4bbf-af8c-7dcdd3bd4008@oss.qualcomm.com> (raw)
In-Reply-To: <75e435db-a24a-4852-8ca2-23f46e161fcd@oss.qualcomm.com>



On 6/22/2026 8:15 PM, Bibek Kumar Patro wrote:
> 
> 
> On 6/18/2026 9:34 PM, Michael Kelley wrote:
>> From: bibek.patro@oss.qualcomm.com <bibek.patro@oss.qualcomm.com> 
>> Sent: Tuesday, June 16, 2026 2:36 PM
>>>
>>> From: Jagadeesh Pagadala <jpagadal@qti.qualcomm.com>
>>>
>>> The SWIOTLB bounce buffer pool size is hardcoded at 64 MB via
>>> IO_TLB_DEFAULT_SIZE with no compile-time knob to adjust it. On
>>> memory-constrained embedded or mobile platforms equipped with a
>>> hardware IOMMU (e.g., ARM SMMU) covering most DMA-capable devices,
>>> reserving 64 MB at boot is unnecessarily wasteful — the SWIOTLB is
>>> only exercised for devices that bypass the IOMMU or have restricted
>>> DMA address ranges.
>>>
>>> Introduce CONFIG_SWIOTLB_DEFAULT_SIZE_MB, an integer Kconfig option
>>> (range 1–64 MB, default 64) that allows platforms to set a smaller
>>> compile-time default. IO_TLB_DEFAULT_SIZE is updated to derive from
>>> this value when CONFIG_SWIOTLB is enabled, preserving the existing
>>> 64 MB default when the option is not configured.
>>>
>>> The runtime "swiotlb=<nslabs>" kernel parameter override remains
>>> fully supported and takes precedence over the compile-time default.
>>>
>>> Signed-off-by: Jagadeesh Pagadala <jpagadal@qti.qualcomm.com>
>>> Signed-off-by: Bibek Kumar Patro <bibek.patro@oss.qualcomm.com>
>>> ---
>>> The SWIOTLB bounce buffer pool size is hardcoded at 64 MB. On
>>> memory-constrained platforms with a hardware IOMMU (e.g., ARM SMMU),
>>> this reservation is wasteful as SWIOTLB is only needed for devices
>>> that bypass the IOMMU or have restricted DMA address ranges.
>>>
>>> Introduce CONFIG_SWIOTLB_DEFAULT_SIZE_MB (range 1–64 MB, default 64)
>>> to allow a smaller compile-time default. The runtime "swiotlb="
>>> parameter override remains supported and takes precedence.
>>>
>>> Before (default 64 MB):
>>>    [    0.000000] software IO TLB: area num 8.
>>>    [    0.000000] software IO TLB: mapped [mem 
>>> 0x00000000fbfff000-0x00000000fffff000] (64MB)
>>>
>>> After (CONFIG_SWIOTLB_DEFAULT_SIZE_MB=2):
>>>    [    0.000000] software IO TLB: area num 8.
>>>    [    0.000000] software IO TLB: SWIOTLB bounce buffer size roundup 
>>> to 2MB
>>>    [    0.000000] software IO TLB: mapped [mem 
>>> 0x00000000ffdff000-0x00000000fffff000] (2MB)
>>
>> This message sequence is surprising to me -- there should not be any
>> roundup if the default size is 2 MiB and there are 8 CPUs. I ran the 
>> patch
>> with 8 CPUs and set CONFIG_SWIOTLB_DEFAULT_SIZE_MB=2, and
>> no roundup was reported. I'm curious as to what configuration produced
>> the "roundup" message.
>>

I might have misunderstood your query Michael, you're correct.

I rechecked my system configuration with 8 CPUs and
CONFIG_SWIOTLB_DEFAULT_SIZE_MB=2, and I did not get the "roundup"
message. I did a few experiments while developing the patch initially
with CONFIG_SWIOTLB_DEFAULT_SIZE_MB across a range of values.
CONFIG_SWIOTLB_DEFAULT_SIZE_MB=1 gives the roundup message:

   [    0.000000] software IO TLB: area num 8.
   [    0.000000] software IO TLB: SWIOTLB bounce buffer size roundup to 2MB
   [    0.000000] software IO TLB: mapped [mem 
0x00000000ffdff000-0x00000000fffff000] (2MB)

With CONFIG_SWIOTLB_DEFAULT_SIZE_MB=1:

   nslabs = CONFIG_SWIOTLB_DEFAULT_SIZE_MB << 9 = 1 << 9 = 512

With 8 CPUs, default_nareas = 8, so the minimum required nslabs is:

   IO_TLB_SEGSIZE * default_nareas = 128 * 8 = 1024

Since 512 < 1024, nslabs is rounded up to 1024 (2MB), which explains
the roundup message.
I have incorrectly labelled this log in cover letter by posting the logs 
for CONFIG_SWIOTLB_DEFAULT_SIZE_MB=1 instead of
CONFIG_SWIOTLB_DEFAULT_SIZE_MB=2
I will correct this info in the cover letter while sending the next
revision along with the documentation update as you suggested.

Thanks & regards,
Bibek

> 
> I see inside swiotlb.c, we have a print for rounding off based on the
> number of slabs, inside the check for "round_up_default_nslabs()"
> pr_info("SWIOTLB bounce buffer size roundup to %luMB",
> 
> Probability of getting the print based on the number of slabs.
> <I am assuming your configuration is having nslabs in power of 2>
> 
> 
>> Also, there's some text in Documentation/core-api/swiotlb.rst that
>> describes the default size of the swiotlb, and how it can be overridden
>> with the swiotlb= kernel boot option. This patch should include an update
>> to that text to mention the new CONFIG option.
>>
> 
> Ack, thanks for this suggestion. I will incorporate in next revision.
> It would be a good information for someone trying a similar approach for
> setting the default option to custom value.
> 
> Thanks & regards,
> Bibek
> 
>> Michael
>>
>>> ---
>>>   include/linux/swiotlb.h |  8 ++++++--
>>>   kernel/dma/Kconfig      | 22 ++++++++++++++++++++++
>>>   2 files changed, 28 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/include/linux/swiotlb.h b/include/linux/swiotlb.h
>>> index 3dae0f592063..1665a9ce8f94 100644
>>> --- a/include/linux/swiotlb.h
>>> +++ b/include/linux/swiotlb.h
>>> @@ -32,8 +32,12 @@ struct scatterlist;
>>>   #define IO_TLB_SHIFT 11
>>>   #define IO_TLB_SIZE (1 << IO_TLB_SHIFT)
>>>
>>> -/* default to 64MB */
>>> -#define IO_TLB_DEFAULT_SIZE (64UL<<20)
>>> +/* compile-time default; overridable via 
>>> CONFIG_SWIOTLB_DEFAULT_SIZE_MB */
>>> +#ifdef CONFIG_SWIOTLB
>>> +#define IO_TLB_DEFAULT_SIZE ((unsigned 
>>> long)CONFIG_SWIOTLB_DEFAULT_SIZE_MB << 20)
>>> +#else
>>> +#define IO_TLB_DEFAULT_SIZE (64UL << 20)
>>> +#endif
>>>
>>>   unsigned long swiotlb_size_or_default(void);
>>>   void __init swiotlb_init_remap(bool addressing_limit, unsigned int 
>>> flags,
>>> diff --git a/kernel/dma/Kconfig b/kernel/dma/Kconfig
>>> index 0a4ba21a57a7..3830a63ae032 100644
>>> --- a/kernel/dma/Kconfig
>>> +++ b/kernel/dma/Kconfig
>>> @@ -86,6 +86,28 @@ config SWIOTLB
>>>       bool
>>>       select NEED_DMA_MAP_STATE
>>>
>>> +config SWIOTLB_DEFAULT_SIZE_MB
>>> +    int "Default SWIOTLB bounce buffer size in MB"
>>> +    depends on SWIOTLB
>>> +    range 1 64
>>> +    default 64
>>> +    help
>>> +      Sets the default size of the software IO TLB (SWIOTLB) bounce 
>>> buffer
>>> +      pool allocated at boot time. The default is 64 MB.
>>> +
>>> +      On memory-constrained embedded or mobile platforms (e.g., 
>>> those with
>>> +      a hardware IOMMU such as ARM SMMU covering most DMA-capable 
>>> devices),
>>> +      a smaller value such as 4 or 8 MB may be sufficient. The 
>>> SWIOTLB is
>>> +      then only needed for devices that bypass the IOMMU or have 
>>> restricted
>>> +      DMA address ranges.
>>> +
>>> +      The minimum allowed value is 1 MB. This compile-time default 
>>> can be
>>> +      overridden at runtime using the "swiotlb=<nslabs>" kernel 
>>> command line
>>> +      parameter. Refer to Documentation/admin-guide/kernel- 
>>> parameters.txt
>>> +      for details.
>>> +
>>> +      If unsure, leave at the default value of 64.
>>> +
>>>   config SWIOTLB_DYNAMIC
>>>       bool "Dynamic allocation of DMA bounce buffers"
>>>       default n
>>>
>>> ---
>>> base-commit: 4fa3f5fabb30bf00d7475d5a33459ea83d639bf9
>>> change-id: 20260617-swiotlb-c215ce0b23f7
>>>
>>> Best regards,
>>> -- 
>>> Bibek Kumar Patro <bibek.patro@oss.qualcomm.com>
>>>
>>
> 


  reply	other threads:[~2026-07-02 13:44 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-16 21:36 bibek.patro
2026-06-17  8:47 ` Mostafa Saleh
2026-06-17 16:13   ` Bibek Kumar Patro
2026-06-18 16:04 ` Michael Kelley
2026-06-22 14:45   ` Bibek Kumar Patro
2026-07-02 13:44     ` Bibek Kumar Patro [this message]
2026-07-02 15:48       ` Michael Kelley

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=70dd2528-e0b3-4bbf-af8c-7dcdd3bd4008@oss.qualcomm.com \
    --to=bibek.patro@oss.qualcomm.com \
    --cc=iommu@lists.linux.dev \
    --cc=jpagadal@qti.qualcomm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=m.szyprowski@samsung.com \
    --cc=mhklinux@outlook.com \
    --cc=robin.murphy@arm.com \
    /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