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

[Zeng, Jun1]

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.

-----Original Message-----
From: Keith Busch <kbusch@xxxxxxxxxx> 
Sent: Friday, July 17, 2026 4:53 AM
To: Zeng, Jun1 <jun1.zeng@xxxxxxxxx>
Cc: axboe@xxxxxxxxx; hch@xxxxxx; sagi@xxxxxxxxxxx; linux-nvme@xxxxxxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; Shevchenko, Andriy <andriy.shevchenko@xxxxxxxxx>; Cao, Gang <gang.cao@xxxxxxxxx>; Jin, Jun I <jun.i.jin@xxxxxxxxx>; Hu, Yong <yong.hu@xxxxxxxxx>; Fang, Liang A <liang.a.fang@xxxxxxxxx>
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.