From: Naman Jain <namjain@linux.microsoft.com>
To: Michael Kelley <mhklinux@outlook.com>,
Andrew Morton <akpm@linux-foundation.org>,
Thomas Gleixner <tglx@kernel.org>,
Ming Lei <tom.leiming@gmail.com>, Ming Lei <ming.lei@redhat.com>
Cc: Wangyang Guo <wangyang.guo@intel.com>,
Tianyou Li <tianyou.li@intel.com>,
Tim Chen <tim.c.chen@linux.intel.com>,
Long Li <longli@microsoft.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-hyperv@vger.kernel.org" <linux-hyperv@vger.kernel.org>
Subject: Re: [PATCH v2] lib/group_cpus: rotate extra groups to avoid IRQ stacking
Date: Wed, 2 Sep 2026 10:32:52 +0530 [thread overview]
Message-ID: <19005077-4dde-4193-aafa-5b248a2131a6@linux.microsoft.com> (raw)
In-Reply-To: <SN6PR02MB4157B73B333F08702875110ED4A82@SN6PR02MB4157.namprd02.prod.outlook.com>
On 9/1/2026 5:32 AM, Michael Kelley wrote:
> From: Naman Jain <namjain@linux.microsoft.com> Sent: Sunday, August 9, 2026 11:22 PM
>>
>> group_cpus_evenly() computes how a device's queue interrupts are spread
>> across CPUs. It backs managed-interrupt affinity (kernel/irq/affinity.c)
>> and block-multiqueue mappings (block/blk-mq-cpumap.c), and is invoked
>> independently by every device that uses them - NVMe, NICs, storage HBAs,
>> and virtio devices. Its output is deterministic, i.e. for a given
>> topology, two similar devices produce an identical group-to-CPU mapping.
>>
>> When ngroups < ncpus, some groups end up with only a single CPU. An
>
> This is not quite accurate. The condition is ncpus/2 < ngroups < ncpus.
> If ngroups is <= ncpus/2, then all groups have at least 2 CPUs. If ngroups
> is <= ncpus/3, then all groups have at least 3 CPUs, and so on. Rotating which
> groups get the "extra" CPUs can be somewhat helpful even when all groups
> have at least 2 CPUs. But as the minimum number of CPUs per group
> increases, avoiding excessive stacking depends on how well the irqchip driver
> does spreading when picking the effective affinity CPU from the multiple CPUs
> assigned to the group (per our discussion elsewhere in this thread).
>
You're right. I should simplify this to something like this “When the
allocation leaves some groups with only a single CPU, those IRQs are
forced onto the same CPUs and are stacked up.”
>> interrupt whose mask has one CPU can only run there, making that CPU a
>> "hot" handler. Because the mapping is deterministic, identical devices
>> compute the same layout and stack all their single-CPU IRQs onto the
>> very same CPUs, leaving the rest of the system idle.
>>
>> This is easy to hit in practice. On an Azure L96as_v4 VM (96 vCPUs, 2
>> NUMA nodes of 48 CPUs, 6 NVMe disks with 62 I/O queues each),
>> group_cpus_evenly() splits each disk's 62 queues into 31 per node over
>> 48 CPUs. 48 does not divide evenly by 31:
>
> And FWIW, this example meets the stricter condition that I describe above ....
True.
>
>>
>> per NUMA node: 48 CPUs / 31 queues
>> 17 groups get 2 CPUs (cover 34 CPUs)
>> 14 groups get 1 CPU (cover 14 CPUs) <- single-CPU "hot" queues
>>
>> That is 14 hot queues per node, 28 per disk. All 6 disks land them on
>> the same 28 CPUs, so 168 hot interrupts pile onto 28 of 96 CPUs while
>> two-thirds of the system handles none:
>>
>> Before (per-CPU, disks whose IRQs it services):
>> CPU 0: 3 disks ... CPU 34: 6 disks (all six)
>> CPU 1: 3 disks ... CPU 47: 6 disks (all six)
>> Summary: 28 CPUs (34-47, 82-95) served all 6 disks and the other 68
>> served only 3. Those 28 CPUs cap throughput and inflate tail
>> latency while most of the system is idle.
>>
>> Fix this by introducing a per-caller rotation via a static atomic
>> counter (group_spread_cnt). Each call to group_cpus_evenly() takes a
>> unique spread_offset, applied to the two decisions that were previously
>> deterministic:
>>
>> 1) Cluster-level rotation in __try_group_cluster_cpus(): after
>> alloc_groups_to_nodes() distributes groups proportionally across
>> clusters, integer rounding leaves some clusters with one extra
>> group. The extras are redistributed starting from a rotated
>> position, with a stride of ncluster/total_extra to minimize overlap
>> between consecutive callers. A multi-pass fallback ensures all
>> extras are placed even when some clusters are at capacity.
>>
>> 2) Intra-cluster rotation in assign_cpus_to_groups(): the sequential
>> extra assignment is replaced with a modular expression,
>> (v + spread_offset) % nv->ngroups < extra_grps
>> rotating which groups within a cluster receive the extra CPU.
>>
>> Nothing else about the layout changes - same queue count, same NUMA
>> weighting, same full CPU coverage and locality. Each caller simply
>> starts its mapping from a different point, and each individual call
>> still produces a valid, fair distribution. Across callers, different
>> CPUs absorb the single-CPU group IRQ load:
>>
>> After (same setup, with the rotation):
>> CPU 0: 4 disks CPU 2: 4 disks CPU 47: 4 disks
>> CPU 1: 4 disks CPU 3: 4 disks ...
>> Summary: no CPU serves more than 4 disks, and all 96 CPUs are used.
>>
>> The total interrupt work is unchanged - every CPU still handles one
>> queue per disk; only the placement of the single-CPU hot queues moves.
>> This benefits every managed-IRQ, blk-mq, and virtio-vdpa / virtio-fs
>> device with no driver changes.
>>
>> Because the offset comes from a global counter advanced once per call,
>> the mapping now depends on call (device probe) order. A given device's
>> exact layout can differ from one boot to the next, and a later recompute
>> (e.g. a blk-mq remap) may pick a different layout. Every such layout is
>> still valid, fair, and proportional - only the choice among equally good
>> mappings varies.
>>
>> On a 96-vCPU Hyper-V VM running 4K random-read fio across 6 NVMe disks,
>> worst-disk degradation versus average dropped from 11% to 5%, and the
>> previously penalized disks gained 12% IOPS at 10% lower latency.
>>
>> Fixes: 89802ca36c96 ("lib/group_cpus: make group CPU cluster aware")
>> Co-developed-by: Long Li <longli@microsoft.com>
>> Signed-off-by: Long Li <longli@microsoft.com>
>> Signed-off-by: Naman Jain <namjain@linux.microsoft.com>
>> ---
>> Changes since v1
>> (https://lore.kernel.org/all/20260324075352.2326972-1-namjain@linux.microsoft.com/):
>> - Cluster base is now a per-cluster proportional floor
>> (ngroups * cap / ncpus) instead of the global per-cluster minimum,
>> so proportional weighting is preserved on asymmetric (e.g.
>> big.LITTLE) cluster topologies. (Sashiko review)
>> - Document that the rotation offset is call/probe-order dependent: a
>> device's exact layout may vary across boots and recomputes (each
>> layout is still valid, fair, and proportional).
>> - Rewrite the commit message with a worked example and fio numbers.
>>
>> lib/group_cpus.c | 149 +++++++++++++++++++++++++++++++++++++++++++----
>> 1 file changed, 137 insertions(+), 12 deletions(-)
>>
>> diff --git a/lib/group_cpus.c b/lib/group_cpus.c
>> index e6e18d7a49bba..8bed0f9d2110b 100644
>> --- a/lib/group_cpus.c
>> +++ b/lib/group_cpus.c
>> @@ -7,6 +7,7 @@
>> #include <linux/slab.h>
>> #include <linux/cpu.h>
>> #include <linux/sort.h>
>> +#include <linux/atomic.h>
>> #include <linux/group_cpus.h>
>>
>> #ifdef CONFIG_SMP
>> @@ -255,12 +256,20 @@ static void alloc_nodes_groups(unsigned int numgrps,
>> alloc_groups_to_nodes(numgrps, numcpus, node_groups, nr_node_ids);
>> }
>>
>> +/*
>> + * Per-caller rotation counter for group_cpus_evenly().
>> + * Wrapping is harmless: the offset is only used modulo small values
>> + * (ncluster or nv->ngroups), so any unsigned value works.
>> + */
>> +static atomic_t group_spread_cnt = ATOMIC_INIT(0);
>> +
>> static void assign_cpus_to_groups(unsigned int ncpus,
>> struct cpumask *nmsk,
>> struct node_groups *nv,
>> struct cpumask *masks,
>> unsigned int *curgrp,
>> - unsigned int last_grp)
>> + unsigned int last_grp,
>> + unsigned int spread_offset)
>> {
>> unsigned int v, cpus_per_grp, extra_grps;
>> /* Account for rounding errors */
>> @@ -270,11 +279,15 @@ static void assign_cpus_to_groups(unsigned int ncpus,
>> for (v = 0; v < nv->ngroups; v++, *curgrp += 1) {
>> cpus_per_grp = ncpus / nv->ngroups;
>>
>> - /* Account for extra groups to compensate rounding errors */
>> - if (extra_grps) {
>> + /*
>> + * Rotate which groups get the extra CPU so that
>> + * successive callers produce different mappings,
>> + * avoiding IRQ stacking when multiple devices
>> + * share the same CPU topology.
>> + */
>> + if (extra_grps &&
>
> Explicitly testing extra_grps for zero isn't necessary. If it is
> zero, the "less than" test below will always be false anyway.
>
That is true, but the intention was to improve readability of this
block. Unless you really feel that this should be removed, I would
prefer to retain this.
>> + (v + spread_offset) % nv->ngroups < extra_grps)
>> cpus_per_grp++;
>> - --extra_grps;
>> - }
>>
>> /*
>> * wrapping has to be considered given 'startgrp'
>> @@ -361,7 +374,8 @@ static bool __try_group_cluster_cpus(unsigned int ncpus,
>> struct cpumask *node_cpumask,
>> struct cpumask *masks,
>> unsigned int *curgrp,
>> - unsigned int last_grp)
>> + unsigned int last_grp,
>> + unsigned int spread_offset)
>> {
>> struct node_groups *cluster_groups;
>> const struct cpumask **clusters;
>> @@ -379,6 +393,111 @@ static bool __try_group_cluster_cpus(unsigned int ncpus,
>> if (ncluster == 0)
>> goto fail_no_clusters;
>>
>> + /*
>> + * Rotate which clusters receive extra groups so that different
>> + * callers of group_cpus_evenly() produce different group-to-CPU
>> + * mappings. Without this, all devices get identical affinity
>> + * masks, causing IRQ stacking on CPUs assigned single-CPU groups.
>
> s/assigned/assigned to/
>
>> + *
>> + * alloc_groups_to_nodes() distributes ngroups proportionally, but
>> + * integer rounding causes some clusters to get one more group
>> + * than others. The assignment is deterministic, so every device
>> + * gets the same mapping. Fix: compute a proportional floor for
>> + * each cluster (ngroups * cap / ncpus), collect only the
>> + * rounding-induced extras, then redistribute them starting from
>> + * a rotated position. This preserves the proportional weighting
>> + * across differently-sized clusters while rotating the rounding
>> + * extras, keeping the rotation effective on both symmetric and
>> + * asymmetric cluster topologies.
>> + *
>> + * Note: after alloc_groups_to_nodes(), cluster_groups[].ngroups
>> + * holds the group count (the union no longer holds per-cluster CPU
>> + * counts), so each cluster's CPU capacity (cap) is taken from its
>
> Having to recompute "cap" three times in the code below is fairly clumsy.
> Is there any reason that cluster_groups[].ncpus and .ngroups need to be a
> union? If they were separate fields, then "cap" would be immediately
> available when you need it. I looked back through the commit history
> and LKML discussion for when the union was originally added, and I
> didn't find any explanation for why it is a union. A union saves a bit
> of memory, but the overall amount of memory here is small, so the
> implementation doesn't need to be particularly stingy.
I'll remove the union, and simplify this "cap" re-computation.
>
>> + * mask. The ncpus divisor is the function parameter, which equals
>> + * the sum of the per-cluster caps.
>> + */
>> + if (ncluster > 1) {
>> + unsigned int total_extra = 0;
>> + unsigned int start, stride;
>> +
>> + /*
>> + * Compute a per-cluster proportional floor and collect
>> + * only the rounding-induced extras for redistribution.
>> + *
>> + * Each cluster's floor is ngroups * cap / ncpus, which
>> + * preserves its proportional share. Only the rounding
>> + * remainders (typically one per cluster) are collected
>> + * for rotated redistribution, keeping the rotation
>> + * effective even on asymmetric topologies (e.g.
>> + * big.LITTLE) where differently-sized clusters would
>> + * otherwise absorb all extras deterministically.
>> + */
>> + for (i = 0; i < ncluster; i++) {
>> + unsigned int cap, prop_floor, base;
>> +
>> + cap = cpumask_weight_and(clusters[cluster_groups[i].id],
>> + node_cpumask);
>> + prop_floor = ngroups * cap / ncpus;
>> +
>> + /*
>> + * Use proportional floor as base. Ensure at
>> + * least 1 group per cluster, and never exceed
>> + * alloc_groups_to_nodes()'s original allocation
>> + * (which may be less than prop_floor when small
>> + * clusters consumed groups via max(1,...)).
>> + */
>> + base = prop_floor > 0 ? prop_floor : 1;
>> + if (base > cluster_groups[i].ngroups)
>> + base = cluster_groups[i].ngroups;
>> +
>> + total_extra += cluster_groups[i].ngroups - base;
>> + cluster_groups[i].ngroups = base;
>> + }
>
> We had a separate discussion about how your new code here should
> go with alloc_groups_to_nodes() so that it is also applied at the NUMA
> node level. You said you had it working. Question: Did you combine the
> above "for" loop with the "for" loop in alloc_groups_to_nodes()? It
> seems unnecessarily complex to do group allocations, including extras,
> using the "for" loop in alloc_groups_to_nodes(), and then follow that
> with another "for" loop here to figure out which nodes got extras and
> strip them out. A single loop should be able to set all the nodes to
> their base value and count the extras.
>
I just did a prototype and had not combined it yet. I'll try to combine
them into a single function now.
>> +
>> + /*
>> + * Redistribute rounding extras using a stride to scatter
>> + * them across clusters. With stride = ncluster / extras,
>> + * consecutive callers' extra sets overlap minimally
>> + * (e.g. max 2 overlap for 6 callers with 24 clusters
>> + * and 7 extras, vs 6 overlap with stride 1).
>> + */
>> + start = spread_offset % ncluster;
>> + stride = (total_extra > 0 && total_extra < ncluster) ?
>> + ncluster / total_extra : 1;
>> +
>> + for (i = 0; i < ncluster && total_extra > 0; i++) {
>> + unsigned int idx =
>> + (start + i * stride) % ncluster;
>> + unsigned int cap;
>> +
>> + cap = cpumask_weight_and(clusters[cluster_groups[idx].id],
>> + node_cpumask);
>> + if (cluster_groups[idx].ngroups < cap) {
>> + cluster_groups[idx].ngroups++;
>> + total_extra--;
>> + }
>> + }
>> +
>> + /* Fallback: place remaining extras wherever they fit */
>
> Just so I'm clear, you could have "remaining extras" because a stride > 1
> in the previous loop could miss some clusters/nodes that have available
> space, depending on how the arithmetic works out. The code below
> does essentially the same thing, but with a stride of 1 so that every
> node is checked. And you might have to make multiple passes in
> case some nodes have space for two or more extras. But you know
> there's enough space available somewhere.
>
> Is my understanding correct?
>
Yes, this is correct.
>> + while (total_extra > 0) {
>> + unsigned int placed = 0;
>> +
>> + for (i = 0; i < ncluster && total_extra > 0; i++) {
>> + unsigned int cap;
>> +
>> + cap = cpumask_weight_and(clusters[cluster_groups[i].id],
>> + node_cpumask);
>> + if (cluster_groups[i].ngroups < cap) {
>> + cluster_groups[i].ngroups++;
>> + total_extra--;
>> + placed++;
>> + }
>> + }
>> + if (!placed)
>> + break;
>
> Is the control variable "placed" necessary? If all the extra groups are
> guaranteed to fit somewhere, then total_extra should go to zero and
> the checks on total_extra > 0 will break out of the loops. Thinking about
> it from the other direction, if the "for" loop ever completed without
> incrementing "placed", wouldn't that mean total_extra is still
> non-zero, and you have an extra group that isn't assigned to a
> cluster/node?
>
> Michael
It's not required. I should remove it.
Regards,
Naman
next prev parent reply other threads:[~2026-09-02 5:02 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-10 6:21 Naman Jain
2026-08-10 8:47 ` Naman Jain
2026-08-23 15:47 ` Michael Kelley
2026-08-24 14:35 ` Naman Jain
2026-08-26 2:01 ` Michael Kelley
2026-08-27 9:11 ` Naman Jain
2026-08-30 23:57 ` Michael Kelley
2026-08-31 5:31 ` Naman Jain
2026-09-01 0:02 ` Michael Kelley
2026-09-02 5:02 ` Naman Jain [this message]
2026-09-02 16:57 ` Michael Kelley
2026-09-03 3:49 ` Naman Jain
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=19005077-4dde-4193-aafa-5b248a2131a6@linux.microsoft.com \
--to=namjain@linux.microsoft.com \
--cc=akpm@linux-foundation.org \
--cc=linux-hyperv@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=longli@microsoft.com \
--cc=mhklinux@outlook.com \
--cc=ming.lei@redhat.com \
--cc=tglx@kernel.org \
--cc=tianyou.li@intel.com \
--cc=tim.c.chen@linux.intel.com \
--cc=tom.leiming@gmail.com \
--cc=wangyang.guo@intel.com \
/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
all inboxes | Powered by JetHome®