Re: [RFC PATCH] nvme-pci: adaptively poll completions on busy queues

> From: "changfengnan"<[email protected]>
> Date:=C2=A0 Tue, Jul 28, 2026, 14:19
> Subject:=C2=A0 Re: [RFC PATCH] nvme-pci: adaptively poll completions on b=
usy queues
> To: "Christoph Hellwig"<[email protected]>
> Cc: <[email protected]>, "Keith Busch"<[email protected]>, "=
Jens Axboe"<[email protected]>, "Christoph Hellwig"<[email protected]>, "Sagi Grimbe=
rg"<[email protected]>, "Bart Van Assche"<[email protected]>, "Andy Shevche=
nko"<[email protected]>, "Thomas Gleixner"<[email protected]>, "Jun=
 Zeng"<[email protected]>, "Gang Cao"<[email protected]>, "Jun I Jin"<ju=
[email protected]>, "Liang A Fang"<[email protected]>, "Yong Hu"<yong.=
[email protected]>, <[email protected]>, "Guzebing"<guzebing@bytedanc=
e.com>
>=C2=A0
> > From: "Christoph Hellwig"<[email protected]>
> > Date:=C2=A0 Tue, Jul 28, 2026, 12:44
> > Subject:=C2=A0 Re: [RFC PATCH] nvme-pci: adaptively poll completions on=
 busy queues
> > To: "changfengnan"<[email protected]>
> > Cc: <[email protected]>, "Keith Busch"<[email protected]>,=
 "Jens Axboe"<[email protected]>, "Christoph Hellwig"<[email protected]>, "Sagi Grim=
berg"<[email protected]>, "Bart Van Assche"<[email protected]>, "Andy Shevc=
henko"<[email protected]>, "Thomas Gleixner"<[email protected]>, "J=
un Zeng"<[email protected]>, "Gang Cao"<[email protected]>, "Jun I Jin"<=
[email protected]>, "Liang A Fang"<[email protected]>, "Yong Hu"<yon=
[email protected]>, <[email protected]>, "Guzebing"<guzebing@byteda=
nce.com>
> > On Tue, Jul 28, 2026 at 10:24:52AM +0800, changfengnan wrote:
> > > The patch showed 50 confirmed throughput improvements, with a median =
gain of 25.2%
> > > and a maximum gain of 63.0%. Only five cases showed confirmed regress=
ions;
> >=C2=A0
> > Can you drill down into the regression and figure out why they happen
> > and if we can mitigate them? =C2=A0It would be nice if we could find a =
way
> > to avoid major regressions and enable the adaptive mode by default.
>=C2=A0
> Of course, we=E2=80=99ll continue to investigate this issue to minimize p=
erformance
> regressions. As for enabling it by default, it=E2=80=99s too early to say=
=E2=80=94we need
> more testing to verify this, such as seeing how it performs on Gen3/Gen4
> NVMe drives.

Now I can answer this question: When QD=3D33/34, after one or two CQEs are
processed, the number of pending commands is exactly 32, so the system
enters a polling state. However, the number of pending I/O operations does
not guarantee that the CQ will refill quickly. On Samsung drives, the CQ
typically empties after one round of processing. At this point, `fsleep(20)=
` is
called, so new CQEs must wait when they arrive. This delays CQE processing
and causes IOPS to drop. At higher QD, on the other hand, keeps the CQ
sufficiently full, making polling more efficient. Simply adjusting paramete=
rs
does not solve the problem, because this approach confuses the number of
in-flight I/Os with completion density. A high number of in-flight I/Os doe=
s not
necessarily mean that using poll=C2=A0 is more efficient.=C2=A0
Therefore, we developed an alternative solution to address this issue.
https://lore.kernel.org/linux-nvme/20260806031058.40176-1-changfengnan@byte=
dance.com/T/#u
>=C2=A0
> >=C2=A0