Re: [RESEND RFC PATCH v2] nvme-pci: add adaptive interrupt polling

[Anuj Gupta]

On Thu, Aug 13, 2026 at 10:11:19AM +0800, changfengnan wrote:
> 
> > From: "Keith Busch"<kbusch@xxxxxxxxxx>
> > Date:  Wed, Aug 12, 2026, 04:30
> > Subject:  Re: [RESEND RFC PATCH v2] nvme-pci: add adaptive interrupt polling
> > To: "changfengnan"<changfengnan@xxxxxxxxxxxxx>
> > Cc: <axboe@xxxxxxxxx>, <hch@xxxxxx>, <sagi@xxxxxxxxxxx>, <linux-nvme@xxxxxxxxxxxxxxxxxxx>, <linux-kernel@xxxxxxxxxxxxxxx>, "Guzebing"<guzebing@xxxxxxxxxxxxx>
> > On Tue, Aug 11, 2026 at 10:32:35AM +0800, changfengnan wrote:
> > > The code looks much cleaner when using dim, I'll see if I can replace the
> > > sample-and-poll logic I wrote myself with the dim library. 
> > > I ran a quick test on the POC patch and didn't see any performance
> > > improvements; in fact, there were quite a few regressions. Maybe some
> > > parameters need to be adjusted.
> > 
> > Yeah, I'm just now testing mid-tier devices and it's also performing a
> > bit worse for high throughput workloads. But I hadn't really tried to
> > tune the settings here, and maybe my criteria is all wrong. I was mainly
> > trying to see if we can utilize the dim library before honing in on the
> > right implementation details.
> 
> I tried modifying the original approach to use DIM, but the results were
> consistently poor. Using the original approach, my current optimization
> has managed to keep 4K random read backoff within 2% (tested on 10
> different drive models), but when using DIM, the backoff rate is 10–15%.
> I believe there are several reasons for this:
> 1. The core of NVMe adaptive polling is determining when polling is more
> efficient, but DIM cannot answer this question. Although  irq and poll can
> be disguised as a DIM profile, this is essentially just borrowing the DIM
> framework—the core decision-making still requires writing your own baseline,
> thresholds, backoff, and re-baseline, so the code complexity and volume
> haven’t actually decreased. 
> 2. The DIM state machine is relatively heavy, which reduces performance
> gains under I/O-intensive workloads.
> 
> So I tend to avoid using DIM. Please correct me if I'm wrong.

I also had a similar assesment on DIM. Emperically, with Keith's POC
interrupts per IO drop from ~1.0 to ~0.29 but with a small performance
regression (572K -> 557K IOPS). With your original approach they drop to
~0.03 with a 23% performance gain. The DIM machinery overhead maybe
outweighing the partial interrupt reduction.

> 
> > 
>