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

> From: "Keith Busch"<[email protected]>
> Date:  Wed, Aug 12, 2026, 04:30
> Subject:  Re: [RESEND RFC PATCH v2] nvme-pci: add adaptive interrupt polling
> To: "changfengnan"<[email protected]>
> Cc: <[email protected]>, <[email protected]>, <[email protected]>, <[email protected]>, <[email protected]>, "Guzebing"<[email protected]>
> 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.

>