mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Bibek Kumar Patro <bibek.patro@oss.qualcomm.com>
To: Mostafa Saleh <smostafa@google.com>
Cc: Marek Szyprowski <m.szyprowski@samsung.com>,
	Robin Murphy <robin.murphy@arm.com>,
	iommu@lists.linux.dev, 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: Wed, 17 Jun 2026 21:43:21 +0530	[thread overview]
Message-ID: <6cbf7d5b-cf7c-4b31-b60e-06e508c633ca@oss.qualcomm.com> (raw)
In-Reply-To: <CAFgf54r0oXgaFMQeBOV+jm70XoMUKFAOkRhNLM2FrFa_JhmwKA@mail.gmail.com>



On 6/17/2026 2:17 PM, Mostafa Saleh wrote:
> On Tue, Jun 16, 2026 at 10:36 PM <bibek.patro@oss.qualcomm.com> wrote:
>>
>> 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.
>>
> 
> Just curious, why is not "swiotlb=" enough in your case?
> 

We are looking for an approach where we can set a default value of
IO_TLB_DEFAULT_SIZE to maintain and sustain it for a
specific platform or a kernel configuration.

So introducing a Kconfig tunable seemed to be a maintainable approach
compared to "swiotlb=" runtime variable.
(since defconfig is the right mechanism for platform specific 
compile-time defaults)

Further in case of any bootloader constraints - to make default runtime 
parameter, it might require firmware changes on production devices as 
well. (since in embedded/mobile platforms the kernel command line is 
typically managed by the bootloader)

Thanks & regards,
Bibek

> Thanks,
> Mostafa
> 
>> 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)
>> ---
>>   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-06-17 16:13 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 [this message]
2026-06-18 16:04 ` Michael Kelley
2026-06-22 14:45   ` Bibek Kumar Patro
2026-07-02 13:44     ` Bibek Kumar Patro
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=6cbf7d5b-cf7c-4b31-b60e-06e508c633ca@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=robin.murphy@arm.com \
    --cc=smostafa@google.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