Re: [PATCH v5 0/7] Global Software Interrupt Moderation (GSIM)
From: Luigi Rizzo
Date: Thu Aug 20 2026 - 03:36:27 EST
On Thu, Aug 20, 2026 at 9:09 AM Christoph Hellwig <hch@xxxxxxxxxxxxx> 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.
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