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

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

[Christoph Hellwig]

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.

Also how does this interact with adaptive polling code inside drivers
like NAPI or the upcoming nvme variant?

> 
> 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.
> 
> GSIM does not rely on any special hardware feature.
> 
> Global parameters can be modified at runtime with
> 
>     echo ${VALUE} | sudo tee /proc/irq/sw_moderation/${NAME}
> 
> /proc/irq/sw_moderation/stats exports statistics when enabled.
> 
> and moderation on individual interrupts can be turned on/off at runtime with
> 
>     echo 1 | sudo tee /proc/irq/NN/allow_moderation  # use 0 to disable
> 
> EXAMPLE:
>     # global configuration: 50us, target max 1M intr/s, and 70% in intr
>     echo 50 | sudo tee /proc/irq/sw_moderation/delay_us
>     echo 1000000 | sudo tee /proc/irq/sw_moderation/target_intr_rate
>     echo 70 | sudo tee /proc/irq/sw_moderation/hardirq_percent
> 
>     # allow moderation on all interrupts that support it
>     # remember to periodically check and set the flag for dynamically
>     # created interrupts since the default is 0
>     echo 1 | sudo tee /proc/irq/*/allow_moderation
>     
>     #  check the status
>     grep -r . /proc/irq/*/*/../allow_moderation
> 
>     # look at statistics
>     less /proc/irq/sw_moderation/stats
> 
> PERFORMANCE BENEFITS:
> Below are some experimental results under high load comparing conventional
> moderation with GSIM:
> 
> - 100Gbps NIC, 32 queues: rx goes from 50 Gbps to 92.8 Gbps (line rate).
> - 200Gbps NIC, 10 VMs (total 160 queues): rx goes from 30 Gbps to 190 Gbps (line rate).
> - 12 SSD, 96 queues: 4K random read goes from 6M to 20.5M IOPS (device max).
> 
> In all cases, with adaptive moderatrion, latency up to p95 is unaffected
> at low/moderate load, even if compared with no moderation at all.
> 
> Changes in v5:
> - refactored the commits based on previous feedback
> - various cleanups
> - conditionally reverted parent IRQ mask/unmask, which would completely
>   defeat the mechanism GSIM is based on.
> 
> Changes in v4:
> - added irqdesc and irqdata flags as suggested by maintainer
> - parameters are only configured via independent procfs entries.
>   No module parameters anymore.
> - merged control and interrupt functions back into a single header/C files
> - applied various annotations (lockdep, data_race())
> - formatting and various renaming as suggested by maintainer.
> - added performance measurements with adaptive moderation.
> - removed the mechanism to conditionally enable moderation at interrupt
>   creation. This can be done in userspace and suitable udev extensions
>   will be handled separately.
> 
> Changes in v3:
> - clearly documented architecture in kernel/irq/irq_moderation.c
>   including how to handle enable/disable/mask, interrupt migration,
>   hotplug and suspend.
> - split implementation in 4 files irq_moderation.[ch] and
>   irq_moderation_hook.[ch] for better separation of control plane and
>   "dataplane" (functions ran on each interrupt)
> - limited scope to handle_edge_irq() and handle_fasteoi_irq() which
>   have been tested on actual hardware.
> - tested on Intel (also with intremap=posted_msi), AMD, ARM, with NIC,
>   nvme, vfio
> 
> Changes in v2:
> - many style fixes (mostly on comments) based on reviewers' comments on v1
> - removed background from Documentation/core-api/irq/irq-moderation.rst
> - split procfs handlers
> - moved internal details to kernel/irq/irq_moderation.h
> - use cpu hotplug for per-CPU setup, removed unnecessary arch-specific changes
> - select suitable irqs based on !irqd_is_level_type(irqd) && irqd_is_single_target(irqd)
> - use a static_key to enable/disable the feature
> 
> 
> 
> Luigi Rizzo (7):
>   genirq: Add flags for software interrupt moderation.
>   genirq: Add GSIM infrastructure
>   genirq: Implement core GSIM moderation logic
>   genirq: Integrate GSIM into interrupt flow
>   genirq: Add GSIM user space configuration (procfs)
>   genirq: Adaptive Global Software Interrupt Moderation (GSIM).
>   PCI/MSI: re-enable conditional parent mask/unmask with sw moderation
> 
>  drivers/irqchip/irq-msi-lib.c |   8 +
>  drivers/pci/msi/irqdomain.c   |  20 +
>  include/linux/irq.h           |  11 +-
>  include/linux/irqdesc.h       |  12 +
>  kernel/irq/Kconfig            |  11 +
>  kernel/irq/Makefile           |   1 +
>  kernel/irq/chip.c             |  14 +
>  kernel/irq/debugfs.c          |   3 +
>  kernel/irq/internals.h        |  20 +
>  kernel/irq/irq_moderation.c   | 959 ++++++++++++++++++++++++++++++++++
>  kernel/irq/irq_moderation.h   | 156 ++++++
>  kernel/irq/irqdesc.c          |   1 +
>  kernel/irq/manage.c           |  10 +
>  kernel/irq/proc.c             |   2 +
>  kernel/irq/settings.h         |  17 +
>  15 files changed, 1244 insertions(+), 1 deletion(-)
>  create mode 100644 kernel/irq/irq_moderation.c
>  create mode 100644 kernel/irq/irq_moderation.h
> 
> -- 
> 2.55.0.737.g08866a6d13-goog
> 
> 
---end quoted text---

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

[Luigi Rizzo]

On Thu, Aug 20, 2026 at 9:09 AM Christoph Hellwig <hch@infradead.org> 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

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

[changfengnan]

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