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

> From: "Luigi Rizzo"<[email protected]>
> Date:  Thu, Aug 20, 2026, 15:35
> Subject:  Re: [PATCH v5 0/7] Global Software Interrupt Moderation (GSIM)
> To: "Christoph Hellwig"<[email protected]>
> Cc: "Thomas Gleixner"<[email protected]>, "Marc Zyngier"<[email protected]>, "Luigi Rizzo"<[email protected]>, "Paolo Abeni"<[email protected]>, <[email protected]>, <[email protected]>, "Bjorn Helgaas"<[email protected]>, <[email protected]>, <[email protected]>, "Fengnan Chang"<[email protected]>
> On Thu, Aug 20, 2026 at 9:09 AM Christoph Hellwig <[email protected]> wrote:
> >
> > On Wed, Aug 19, 2026 at 12:43:34PM +0000, Luigi Rizzo wrote:
> > > Configuration is easy and robust. System administrators specify the
> > > maximum targets (moderation delay; interrupt rate; percentage of time
> > > spent in hardirq), and which interrupt sources should be moderated.
> > > Independent per-CPU control loops adjust actual delays to try and keep
> > > metrics within the targets.
> >
> > Can we find a way to autodetect and autoenable this?  A magic go faster
> > mode that needs very specific tuning is annoying compare to sensible
> > defaults.
> 
> As mentioned later, the tunings do not need to be specific,
> because the control loop adjusts the delay to stay within the target,
> and the target is generally just a "don't overload me" value with little
> impact on performance.
> 
> Of course there are many cases (eg small systems with little I/O) where
> moderation is not needed at all so at least one bit of user input is necessary.
> 
> What I normally do is use another small patch to pass the initial settings via
> module parameters, using values similar to those below
> (enable on all interrupts, delay_us=100, target_intr_rate=1000000,
> hardirq_percent=70)
> 
> > 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.

Thanks.

> 
> If NAPI etc manage to keep the interrupt rate/load below the targets,
> then the adaptive controller in GSIM ends up using zero additional delay.
> Otherwise, it gently adjusts the moderation delay so the combination suffices
> to stay within the target.
> 
> All the above assumes the parameters are sensible.
> GSIM or any HW moderation allows up to 1/delay_us interrupts per second, so
> setting delay_us=10 allows up to 100Kintr/s per CPU handling interrupts,
> so there is no way we can throttle interrupts below 100K/s)
> 
> >
> > >
> > > The system is adaptive. Moderation affects only latency and only in
> > > high load scenarios.  Throughput and CPU efficiencly generally benefits
> > > significantly.  Targets don't need to match precisely the platform
> > > limits, and one can make conservative and robust choices. Values like
> > > delay_us=100, target_intr_rate=1000000, hardirq_percent=70 are a very
> > > good starting point.
> 
> cheers
> luigi
>