Re: [PATCH v1 1/1] nvme-pci: adaptive interrupt coalescing

On Fri, Jul 17, 2026 at 04:10:08AM +0300, Zeng, Jun1 wrote:
> Hi Busch, 
> Thanks for your reply. The main reason for implementing this in kernel space
> is the lack of a unified, deployable component in user space to support this
> feature. You see that there are sheer number of OS distributions. This will
> require separate adaptations for each, usability might be compromised,
> and-most importantly-ongoing maintenance and updates would be difficult.
> Meanwhile, nvme driver in kernel space is providing these unified
> capabilities for different kinds of usage.  For the point of using
> atomic_long_inc in cqe polling we can discuss to do it in a proper way.

You need to stop top-posting!

> -----Original Message-----
> From: Keith Busch <[email protected]> 
> Sent: Friday, July 17, 2026 4:53 AM
> To: Zeng, Jun1 <[email protected]>
> Cc: [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; Shevchenko, Andriy <[email protected]>; Cao, Gang <[email protected]>; Jin, Jun I <[email protected]>; Hu, Yong <[email protected]>; Fang, Liang A <[email protected]>
> Subject: Re: [PATCH v1 1/1] nvme-pci: adaptive interrupt coalescing
> 
> On Wed, Jul 15, 2026 at 03:57:03PM +0800, Jun Zeng wrote:
> > Add adaptive interrupt coalescing to improve IOPS for high-throughput 
> > workloads. Monitor IO pressure periodically and enable/disable 
> > coalescing automatically based on IOPS, queue depth, and inflight IO thresholds.
> > This feature is enabled by default, can be controlled through debugfs 
> > variable during runtime.
> 
> Can't you do all this from user space? You'd maybe need the blk-mq debugfs to get access to the individual hctx dispatch numbers, but maybe that's okay?
> 
> The atomic_long_inc where you placed it is especially harmful to polled queues.

-- 
With Best Regards,
Andy Shevchenko