On Fri, Apr 17, 2026 at 02:16:07PM -0600, Jens Axboe wrote: > On 4/17/26 12:28 PM, Bart Van Assche wrote: > > On 3/19/26 3:19 PM, Aaron Tomlin wrote: > >> To guarantee zero performance overhead for production kernels compiled > >> without debugfs, the underlying atomic_t variables and their associated > >> increment routines are strictly guarded behind CONFIG_BLK_DEBUG_FS. > >> When this configuration is disabled, the tracking logic compiles down > >> to a safe no-op. > > > > I don't think that's sufficient. Please use per-cpu counters to > > minimize the overhead for kernels in which debugfs is enabled. > > Agree, this is the usual nonsense of thinking you can hide any overhead > behind a config option, when in practice production kernels very much DO > have CONFIG_DEBUGFS enabled.
Hi Bart, Jens, Thank you both for the candid feedback. I concede that relying on CONFIG_BLK_DEBUG_FS to mitigate the performance impact was a short-sighted approach, as you are absolutely right that debugfs is routinely enabled in modern production environments. The use of an atomic_t variable in this case would indeed introduce unacceptable cache line contention under heavy workloads. I shall address this in the next iteration by transitioning the tracking logic entirely to per-CPU counters. This will ensure the overhead is strictly minimised, irrespective of the build configuration. Thank you again for your time and guidance on this matter. Kind regards, -- Aaron Tomlin
signature.asc
Description: PGP signature
