From: Christoph Hellwig <hch@infradead.org>
To: Luigi Rizzo <lrizzo@google.com>
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>
Subject: Re: [PATCH v5 0/7] Global Software Interrupt Moderation (GSIM)
Date: Thu, 20 Aug 2026 00:09:05 -0700 [thread overview]
Message-ID: <aoaoERD5m1MNvMWd@infradead.org> (raw)
In-Reply-To: <20260819124341.4185621-1-lrizzo@google.com>
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---
next parent reply other threads:[~2026-08-20 7:09 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20260819124341.4185621-1-lrizzo@google.com>
2026-08-20 7:09 ` Christoph Hellwig [this message]
2026-08-20 7:34 ` [PATCH v5 0/7] Global Software Interrupt Moderation (GSIM) Luigi Rizzo
2026-08-20 11:46 ` changfengnan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aoaoERD5m1MNvMWd@infradead.org \
--to=hch@infradead.org \
--cc=bhelgaas@google.com \
--cc=changfengnan@bytedance.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nvme@lists.infradead.org \
--cc=linux-pci@vger.kernel.org \
--cc=lrizzo@google.com \
--cc=maz@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=rizzo.unipi@gmail.com \
--cc=tglx@linutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox