RE: [PATCH] swiotlb: introduce Kconfig option for compile-time default pool size

[Michael Kelley]

From: Bibek Kumar Patro <bibek.patro@xxxxxxxxxxxxxxxx> Sent: Thursday, July 2, 2026 6:45 AM
> 
> On 6/22/2026 8:15 PM, Bibek Kumar Patro wrote:
> >
> >
> > On 6/18/2026 9:34 PM, Michael Kelley wrote:
> >> From: bibek.patro@xxxxxxxxxxxxxxxx <bibek.patro@xxxxxxxxxxxxxxxx>
> >> Sent: Tuesday, June 16, 2026 2:36 PM
> >>>
> >>> From: Jagadeesh Pagadala <jpagadal@xxxxxxxxxxxxxxxx>
> >>>
> >>> 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@xxxxxxxxxxxxxxxx>
> >>> Signed-off-by: Bibek Kumar Patro <bibek.patro@xxxxxxxxxxxxxxxx>
> >>> ---
> >>> 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. That all makes sense now.

Michael