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

Anuj Gupta <[email protected]>
Newsgroups org.infradead.lists.linux-nvme,org.kernel.vger.linux-kernel
Message-ID <mxcthoo4vrlki7smlaqwh64hdyjkuovjrfzsyzdma4ktcrrc4k@g4dph2ouwnbv>
On Thu, Aug 13, 2026 at 10:11:19AM +0800, changfengnan wrote:
> 
> > 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.

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.

> 
> > 
>
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.