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

[Keith Busch <kbusch@kernel.org>]

On Mon, Jul 20, 2026 at 05:05:39PM +0200, Christoph Hellwig wrote:
> On Thu, Jul 16, 2026 at 02:52:41PM -0600, Keith Busch wrote:
> > 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?
> 
> Having these kinds of interfaces where we rely on a userspace daemon
> to be in sync with the kernel implementation are a mess, and really
> lock us out of future improvements in this area.

We can't stop someone from doing this today, though.
 
> > The atomic_long_inc where you placed it is especially harmful to polled
> > queues.
> 
> We really should be able to do this without any counters, as blk-mq keeps
> more than enough statistics.  And of course for polled queues nothing
> related to interrupt coalescing is actually need.
> 
> And we should take a page from the networking playbook and look into
> adaptively switching to polling under high load instead of just
> mitigating interrupts.  An important part of that is to move the CQ
> reaping from irq context to thread context.

Totally. I had a proposal from I think 7 years ago to converge nvme's
threaded IRQ handling: reap the first X entries from hard-irq context,
and if there's more, return IRQ_WAKE_THREAD to poll the rest and future
completions with that queue's interrupt masked (this is one scenario
where NVMe's MSI masking is better than MSI-x, but it's not a big deal).
I can't find the patch though, so I guess it was in the gap that
infradead lost.

Anyway, I think combine that concept with the isolcpus proposal and you
can have full control over which CPUs can dispatch new IO without being
interrupted from CPUs reaping completions. Then we shouldn't need the
spec's coalescing feature.

> But modulo all these caveats adaptive interrupt coalescing / 
> moderation is something we absolute need right now and even more so
> going foward.
> 
> Note that a few month ago there also was as an interesting patchset
> that does global interrupt moderation at the IRQ controller level.
> I don't remember what happened to it and can't find a link to it,
> but adding the interrupt maintainer in case he remembers.