Re: [PATCH v4] dma/swiotlb: decouple high watermark tracking from CONFIG_DEBUG_FS
Marek Szyprowski <[email protected]>
| Newsgroups | dev.linux.lists.iommu,org.kernel.vger.linux-kernel |
|---|---|
| Message-ID | <[email protected]> |
On 12.08.2026 17:01, Michael Kelley wrote: > From: Frank Chen <[email protected]> Sent: Wednesday, August 12, 2026 12:05 AM >> From: chenhuguanshen <[email protected]> >> >> Under heavy concurrent DMA traffic on CoCo VMs, inc_used_and_hiwater() >> performs an atomic_long_add_return() plus a CAS loop on the global >> used_hiwater, and dec_used() performs an atomic_long_sub() on total_used. >> All CPUs contend on the same cacheline, causing measurable throughput >> degradation at scale. >> >> Historically these counters were only compiled in under CONFIG_DEBUG_FS, >> which means production kernels with debugfs paid the atomic overhead >> unconditionally. Make the tracking boot-time opt-in instead so that it >> is disabled by default with near-zero overhead via static_call, and can >> be enabled via "swiotlb=track_hiwater" parameter on demand for debugging. >> >> Note that when CONFIG_DEBUG_FS is enabled but hiwater tracking is disabled, >> the "io_tlb_used" metric reports an approximate value rather than an >> instantaneously exact one. >> >> Suggested-by: Fan Du <[email protected]> >> Signed-off-by: Jun Miao <[email protected]> >> Co-developed-by: Fan Du <[email protected]> >> Signed-off-by: Fan Du <[email protected]> >> Tested-by: chenhuguanshen <[email protected]> >> Signed-off-by: chenhuguanshen <[email protected]> >> >> --- >> v1 -> v2: >> - Change the patch title. >> - Doing the exact hiwater calculation is dynamic and defaults to "off", >> dynamic config would replace being under #ifdef CONFIG_DEBUG_FS >> - The mechanism used for dynamic config needs to be one that is selectable >> on the kernel boot line so that the exact hiwater mark during boot is >> easily available. >> >> v2 -> v3: >> - When track_hiwater is enabled, we keep the original precise hiwater >> calculation backed by the global total_used atomic counter. If disabled, >> we switch to the approximate approach that sums per-area counters to >> derive the total used slot count. >> >> v3 -> v4: >> - Change commit message and documentation. > LGTM. > > Reviewed-by: Michael Kelley <[email protected]> > Tested-by: Michael Kelley <[email protected]> Applied to dma-mapping-for-next, thanks! Best regards -- Marek Szyprowski, PhD Samsung R&D Institute Poland