Message-ID: <b4a61e3d17db7666a2b523fc57fdbb9356eb5191.camel@redhat.com>
Date: Fri, 09 Jan 2026 14:13:32 -0500
From: Radu Rendec <rrendec@...hat.com>
To: "Guo, Wangyang" <wangyang.guo@...el.com>, Andrew Morton
	 <akpm@...ux-foundation.org>
Cc: Thomas Gleixner <tglx@...utronix.de>, linux-kernel@...r.kernel.org, 
 Tianyou Li <tianyou.li@...el.com>, Tim Chen <tim.c.chen@...ux.intel.com>,
 Dan Liang <dan.liang@...el.com>
Subject: Re: [PATCH] lib/group_cpus: make group CPU cluster aware

Hi all,

On Mon, 2025-12-22 at 11:03 +0800, Guo, Wangyang wrote:
> On 12/22/2025 3:10 AM, Andrew Morton wrote:
> > On Fri, 24 Oct 2025 10:30:38 +0800 Wangyang Guo <wangyang.guo@...el.com> wrote:
> > 
> > > As CPU core counts increase, the number of NVMe IRQs may be smaller than
> > > the total number of CPUs. This forces multiple CPUs to share the same
> > > IRQ. If the IRQ affinity and the CPU’s cluster do not align, a
> > > performance penalty can be observed on some platforms.
> > 
> > It would be helpful to quantify "performance penalty".  At least give
> > readers some approximate understanding of how serious this issue is,
> > please.
> > 
> Thanks for your reminder, will update changelog in next version. We see 
> 15%+ performance difference in FIO libaio/randread/bs=8k.
> 
> > > This patch improves IRQ affinity by grouping CPUs by cluster within each
> > > NUMA domain, ensuring better locality between CPUs and their assigned
> > > NVMe IRQs.
> > > 
> > > Reviewed-by: Tianyou Li <tianyou.li@...el.com>
> > > Reviewed-by: Tim Chen <tim.c.chen@...ux.intel.com>
> > > Tested-by: Dan Liang <dan.liang@...el.com>
> > > Signed-off-by: Wangyang Guo <wangyang.guo@...el.com>
> > 
> > Patch hasn't attracted additional review so I'll queue this version for
> > some testing in mm.git's mm-nonmm-unstable branch.  I'll add a
> > note-to-self that a changelog addition is desirable.
> 
> 
> Thanks a lot for your time and support! Please let me know if you have 
> any further comments or guidance. Any feedback would be appreciated.

With this patch applied, I see a weird issue in a qemu x86_64 vm if I
start it with a higher number of max CPUs than active CPUs, for example
`-smp 4,maxcpus=8` on the qemu command line.

What I see is the `while (1)` loop in alloc_cluster_groups() spinning
forever. Removing the `maxcpus=8` from the qemu command line fixes the
issue but so does reverting the patch :)

FWIW, this is my full qemu command line, in case it helps reproduce the
issue.

qemu-system-x86_64 -nographic -m 1G -accel kvm -machine q35,hpet=off \
        -cpu host -smp 4,maxcpus=8 \
        -netdev bridge,br=vbr-nat,id=net0 -device virtio-net-pci,netdev=net0 \
        -drive file=root.img,format=raw,if=virtio \
        -kernel bzImage \
        -append "console=ttyS0 root=/dev/vda1 rw nokaslr" -s

And this is a stack trace extracted from gdb attached to qemu's gdb
server.

#0  check_region_inline (addr=0xffffffff833b7d40 <__per_cpu_offset+32>, 
    size=8, write=false, ret_ip=18446744071582127502)
    at mm/kasan/generic.c:185
#1  __asan_load8 (addr=0xffffffff833b7d40 <__per_cpu_offset+32>)
    at mm/kasan/generic.c:273
#2  0xffffffff8132158e in cpu_l2c_shared_mask (cpu=cpu@...ry=4)
    at arch/x86/include/asm/smp.h:149
#3  cpu_clustergroup_mask (cpu=cpu@...ry=4)
    at arch/x86/kernel/smpboot.c:672
#4  0xffffffff81e9d6b6 in alloc_cluster_groups (ncpus=ncpus@...ry=4, 
    ngroups=ngroups@...ry=4, 
    node_cpumask=node_cpumask@...ry=0xffff88800d7a28e0, 
    msk=0xffff88800d7a24e0, 
    clusters_ptr=clusters_ptr@...ry=0xffffc9000001eef0, 
    cluster_groups_ptr=cluster_groups_ptr@...ry=0xffffc9000001eed0)
    at lib/group_cpus.c:310
#5  0xffffffff81e9da22 in __try_group_cluster_cpus (ncpus=ncpus@...ry=4, 
    ngroups=4, node_cpumask=node_cpumask@...ry=0xffff88800d7a28e0, 
    masks=masks@...ry=0xffff88800e9a8000, 
    curgrp=curgrp@...ry=0xffffc9000001f000, last_grp=last_grp@...ry=4)
    at lib/group_cpus.c:374
#6  0xffffffff81e9decf in __group_cpus_evenly (startgrp=startgrp@...ry=0, 
    numgrps=numgrps@...ry=4, 
    node_to_cpumask=node_to_cpumask@...ry=0xffff88800d7a28a0, 
    cpu_mask=<optimized out>, nmsk=<optimized out>, 
    masks=masks@...ry=0xffff88800e9a8000)
    at lib/group_cpus.c:457
#7  0xffffffff81e9e406 in group_cpus_evenly (numgrps=numgrps@...ry=4, 
    nummasks=nummasks@...ry=0xffffc9000001f248)
    at lib/group_cpus.c:547
#8  0xffffffff8121690c in irq_create_affinity_masks (nvecs=nvecs@...ry=5, 
    affd=affd@...ry=0xffffc9000001f738)
    at kernel/irq/affinity.c:74
#9  0xffffffff81efc253 in msix_setup_interrupts (dev=<optimized out>, 
    entries=<optimized out>, nvec=5, affd=0xffffc9000001f738)
    at drivers/pci/msi/msi.c:694
#10 msix_capability_init (dev=0xffff88800e014000, entries=<optimized out>, 
    nvec=5, affd=<optimized out>)
    at drivers/pci/msi/msi.c:738
#11 __pci_enable_msix_range (dev=dev@...ry=0xffff88800e014000, 
    entries=entries@...ry=0x0, minvec=minvec@...ry=5, maxvec=maxvec@...ry=5, 
    affd=affd@...ry=0xffffc9000001f738, flags=flags@...ry=12)
    at drivers/pci/msi/msi.c:846
#12 0xffffffff81ef9ef3 in pci_alloc_irq_vectors_affinity (
    dev=0xffff88800e014000, min_vecs=min_vecs@...ry=5, 
    max_vecs=max_vecs@...ry=5, flags=flags@...ry=12, 
    affd=affd@...ry=0xffffc9000001f738)
    at drivers/pci/msi/api.c:268
#13 0xffffffff82039d1f in vp_request_msix_vectors (
    vdev=vdev@...ry=0xffff88800e86a000, nvectors=5, 
    per_vq_vectors=per_vq_vectors@...ry=true, desc=<optimized out>, 
    desc@...ry=0xffffc9000001f738)
    at drivers/virtio/virtio_pci_common.c:160
#14 0xffffffff8203a615 in vp_find_vqs_msix (
    vdev=vdev@...ry=0xffff88800e86a000, nvqs=nvqs@...ry=4, 
    vqs=vqs@...ry=0xffff88800d739ac0, 
    vqs_info=vqs_info@...ry=0xffff88800d761100, 
    vector_policy=vector_policy@...ry=VP_VQ_VECTOR_POLICY_EACH, 
    desc=desc@...ry=0xffffc9000001f738)
    at drivers/virtio/virtio_pci_common.c:417
#15 0xffffffff8203ac0a in vp_find_vqs (vdev=vdev@...ry=0xffff88800e86a000, 
    nvqs=4, vqs=0xffff88800d739ac0, vqs_info=0xffff88800d761100, 
    desc=0xffffc9000001f738)
    at drivers/virtio/virtio_pci_common.c:525
#16 0xffffffff82036553 in vp_modern_find_vqs (vdev=0xffff88800e86a000, 
    nvqs=<optimized out>, vqs=<optimized out>, vqs_info=<optimized out>, 
    desc=<optimized out>)
    at drivers/virtio/virtio_pci_modern.c:751
#17 0xffffffff82152ea9 in virtio_find_vqs (vdev=0xffff88800e86a000, nvqs=4, 
    vqs=0xffff88800d739ac0, vqs_info=0xffff88800d761100, 
    desc=0xffffc9000001f738)
    at include/linux/virtio_config.h:298
#18 init_vq (vblk=vblk@...ry=0xffff88800e7fe800)
    at drivers/block/virtio_blk.c:1017
#19 0xffffffff82153212 in virtblk_probe (vdev=0xffff88800e86a000)
    at drivers/block/virtio_blk.c:1470
#20 0xffffffff82024133 in virtio_dev_probe (_d=0xffff88800e86a098)
    at drivers/virtio/virtio.c:347
#21 0xffffffff82114166 in call_driver_probe (dev=dev@...ry=0xffff88800e86a098, 
    drv=drv@...ry=0xffffffff840a5020 <virtio_blk>)
    at drivers/base/dd.c:581
#22 0xffffffff82115038 in really_probe (dev=dev@...ry=0xffff88800e86a098, 
    drv=drv@...ry=0xffffffff840a5020 <virtio_blk>)
    at drivers/base/dd.c:659
#23 0xffffffff821153d9 in __driver_probe_device (
    drv=drv@...ry=0xffffffff840a5020 <virtio_blk>, 
    dev=dev@...ry=0xffff88800e86a098)
    at drivers/base/dd.c:801
#24 0xffffffff8211590a in driver_probe_device (
    drv=drv@...ry=0xffffffff840a5020 <virtio_blk>, 
    dev=dev@...ry=0xffff88800e86a098)
    at drivers/base/dd.c:831
#25 0xffffffff82115c46 in __driver_attach (dev=0xffff88800e86a098, 
    data=0xffffffff840a5020 <virtio_blk>)
    at drivers/base/dd.c:1225
#26 0xffffffff82111700 in bus_for_each_dev (bus=<optimized out>, 
    start=start@...ry=0x0, data=data@...ry=0xffffffff840a5020 <virtio_blk>, 
    fn=fn@...ry=0xffffffff82115b30 <__driver_attach>)
    at drivers/base/bus.c:383
#27 0xffffffff82114738 in driver_attach (
    drv=drv@...ry=0xffffffff840a5020 <virtio_blk>)
    at drivers/base/dd.c:1243
#28 0xffffffff82113860 in bus_add_driver (
    drv=drv@...ry=0xffffffff840a5020 <virtio_blk>)
    at drivers/base/bus.c:715
#29 0xffffffff821171f6 in driver_register (
    drv=drv@...ry=0xffffffff840a5020 <virtio_blk>)
    at drivers/base/driver.c:249
#30 0xffffffff8202306b in __register_virtio_driver (
    driver=driver@...ry=0xffffffff840a5020 <virtio_blk>, owner=owner@...ry=0x0)
    at drivers/virtio/virtio.c:456
#31 0xffffffff84b19134 in virtio_blk_init ()
    at drivers/block/virtio_blk.c:1707
#32 0xffffffff812884eb in do_one_initcall (
    fn=0xffffffff84b190e0 <virtio_blk_init>)
    at init/main.c:1379
#33 0xffffffff84a82ba7 in do_initcall_level (level=6, 
    command_line=0xffff8880090e1880 "console")
    at init/main.c:1441
#34 do_initcalls ()
    at init/main.c:1457
#35 0xffffffff84a82f24 in do_basic_setup ()
    at init/main.c:1476
#36 kernel_init_freeable ()
    at init/main.c:1689
#37 0xffffffff8277ad98 in kernel_init (unused=<optimized out>)
    at init/main.c:1579
#38 0xffffffff812e11fb in ret_from_fork (prev=<optimized out>, 
    regs=0xffffc9000001ff48, fn=0xffffffff8277ad80 <kernel_init>, fn_arg=0x0)
    at arch/x86/kernel/process.c:158
#39 0xffffffff8129390a in ret_from_fork_asm ()
    at arch/x86/entry/entry_64.S:246

-- 
Best regards,
Radu

Powered by blists - more mailing lists