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. > > > >