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

["Fengnan" <changfengnan@bytedance.com>]

在 2026/9/9 16:06, Luigi Rizzo 写道:
> On Wed, Sep 9, 2026 at 8:25 AM Christoph Hellwig <hch@infradead.org> wrote:
>> On Sat, Sep 05, 2026 at 10:30:22PM +0200, Thomas Gleixner wrote:
>>>> 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".
>> I'm not sure they tackle the entirely same problem, although they are
>> very related.
> There is overlap but it is accidental.
> The difference between the two mechanism is the following:
>
> - GSIM addresses hardware limitations (SoCs that create huge PCIe
>    backpressure on each MSIx interrupt, eventually reducing the available
>    bandwidth too much, regardless of how many CPUs can process interrupts).
>    The goal here is to throttle the total MSIx rate, blocking them at
>    the source (PCIe device) rather than later in the interrupt controller.
>
> - the NVME mechanism (and NAPI) aim to amortize interrupt processing
>    overhead. It does so by recreating some fine grained single-source
>    interrupt moderation (something that NICs do in hardware, but NVME
>    does not, with 100us being way too coarse for modern SSDs) and an
>    adaptive scheme to adjust the delay and decide when to kick in.
That's a great summary.

As for generic solutions, I've tried several approaches before, but none 
of them
could achieve the same or close results as NVMe adaptive interrupt polling.
I'm still experimenting with different options.


>
> I think there is a reason for both.
>
> GSIM because it is more general and addresses an issue the others cannot handle
> the subsystem-specific scheme because they can be more efficient
> (eg they can hook into existing helpers like the threaded irq handler,
> call directly the handler without going through the full irq chain,
> use more targeted heuristics to decide when to kick in).
>
> cheers
> luigi