[PATCH v5 0/7] Global Software Interrupt Moderation (GSIM)

[Thomas Gleixner]

On Thu, Aug 20 2026 at 19:46, changfengnan at bytedance.com wrote:
>> From: "Luigi Rizzo"<lrizzo at google.com>
>> Date:  Thu, Aug 20, 2026, 15:35
>> Subject:  Re: [PATCH v5 0/7] Global Software Interrupt Moderation (GSIM)
>> To: "Christoph Hellwig"<hch at infradead.org>
>> Cc: "Thomas Gleixner"<tglx at linutronix.de>, "Marc Zyngier"<maz at kernel.org>, "Luigi Rizzo"<rizzo.unipi at gmail.com>, "Paolo Abeni"<pabeni at redhat.com>, <linux-kernel at vger.kernel.org>, <linux-pci at vger.kernel.org>, "Bjorn Helgaas"<bhelgaas at google.com>, <netdev at vger.kernel.org>, <linux-nvme at lists.infradead.org>, "Fengnan Chang"<changfengnan at bytedance.com>
>> On Thu, Aug 20, 2026 at 9:09 AM Christoph Hellwig <hch at infradead.org> wrote:

Can you please fix yuur mail client so it does not copy all that
redundant headers into your reply?

>> > Also how does this interact with adaptive polling code inside drivers
>> > like NAPI or the upcoming nvme variant?
>> 
>> GSIM acts at hardirq level (so below NAPI, and above device moderation e.g.
>> the one in ethtool -C ...) and is completely orthogonal to those other
>> mechanisms.
>
> Hi Luigi:
> The NVMe variant that Christoph mentioned is this patch of mine.
> https://lore.kernel.org/linux-nvme/d9210bcdf73fbe1ac8b6ec132865609a3ed68688.99d43a8b.dfff.41d1.b07d.0592a12473d2@bytedance.com/T/#m561d136611962055641f331e600e719de1e7c573
> I took a quick look at your implementation, and I wouldn't say our two
> approaches are completely independent.
> I’ve run some tests, the test methods, environment, and data are detailed in
> this document:
> https://docs.google.com/spreadsheets/d/1p3XqVpKgx18QhqTFb0KlJfEW9giWDGSUuoKqCZzdZLg/edit?gid=1100001004#gid=1100001004
>
> it appears that GSIM is only effective in scenarios where multi disks at very high
> IOPS; in some cases, there was a noticeable performance regression. 
> If there’s something wrong with my configuration, please correct me.

So we have a NVME specific mechanism to tackle the same problem and a
more generic version which is subsystem "independent".

Can you folks please coordinate and get your act together so that we
don't end up with two competing mechanisms which make things worse than
they are now.

TBH. I despise the NVME is special approach because it's fricking
obvious that this is _NOT_ a NVME specific issue. But sure NVME is
special as all other subsystems are special.

Q: When do driver folks actually start to look beyond the brim of their
   tea cup?

A: Probably never ...

Thanks,

        tglx