public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Radu Rendec <rrendec@redhat.com>
To: "Guo, Wangyang" <wangyang.guo@intel.com>,
	Andrew Morton <akpm@linux-foundation.org>
Cc: Thomas Gleixner <tglx@linutronix.de>,
	linux-kernel@vger.kernel.org,  Tianyou Li <tianyou.li@intel.com>,
	Tim Chen <tim.c.chen@linux.intel.com>,
	Dan Liang <dan.liang@intel.com>
Subject: Re: [PATCH] lib/group_cpus: make group CPU cluster aware
Date: Fri, 09 Jan 2026 14:13:32 -0500	[thread overview]
Message-ID: <b4a61e3d17db7666a2b523fc57fdbb9356eb5191.camel@redhat.com> (raw)
In-Reply-To: <dadfc308-bf2b-4c54-9518-0d5f6355cf23@intel.com>

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@intel.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@intel.com>
> > > Reviewed-by: Tim Chen <tim.c.chen@linux.intel.com>
> > > Tested-by: Dan Liang <dan.liang@intel.com>
> > > Signed-off-by: Wangyang Guo <wangyang.guo@intel.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@entry=4)
    at arch/x86/include/asm/smp.h:149
#3  cpu_clustergroup_mask (cpu=cpu@entry=4)
    at arch/x86/kernel/smpboot.c:672
#4  0xffffffff81e9d6b6 in alloc_cluster_groups (ncpus=ncpus@entry=4, 
    ngroups=ngroups@entry=4, 
    node_cpumask=node_cpumask@entry=0xffff88800d7a28e0, 
    msk=0xffff88800d7a24e0, 
    clusters_ptr=clusters_ptr@entry=0xffffc9000001eef0, 
    cluster_groups_ptr=cluster_groups_ptr@entry=0xffffc9000001eed0)
    at lib/group_cpus.c:310
#5  0xffffffff81e9da22 in __try_group_cluster_cpus (ncpus=ncpus@entry=4, 
    ngroups=4, node_cpumask=node_cpumask@entry=0xffff88800d7a28e0, 
    masks=masks@entry=0xffff88800e9a8000, 
    curgrp=curgrp@entry=0xffffc9000001f000, last_grp=last_grp@entry=4)
    at lib/group_cpus.c:374
#6  0xffffffff81e9decf in __group_cpus_evenly (startgrp=startgrp@entry=0, 
    numgrps=numgrps@entry=4, 
    node_to_cpumask=node_to_cpumask@entry=0xffff88800d7a28a0, 
    cpu_mask=<optimized out>, nmsk=<optimized out>, 
    masks=masks@entry=0xffff88800e9a8000)
    at lib/group_cpus.c:457
#7  0xffffffff81e9e406 in group_cpus_evenly (numgrps=numgrps@entry=4, 
    nummasks=nummasks@entry=0xffffc9000001f248)
    at lib/group_cpus.c:547
#8  0xffffffff8121690c in irq_create_affinity_masks (nvecs=nvecs@entry=5, 
    affd=affd@entry=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@entry=0xffff88800e014000, 
    entries=entries@entry=0x0, minvec=minvec@entry=5, maxvec=maxvec@entry=5, 
    affd=affd@entry=0xffffc9000001f738, flags=flags@entry=12)
    at drivers/pci/msi/msi.c:846
#12 0xffffffff81ef9ef3 in pci_alloc_irq_vectors_affinity (
    dev=0xffff88800e014000, min_vecs=min_vecs@entry=5, 
    max_vecs=max_vecs@entry=5, flags=flags@entry=12, 
    affd=affd@entry=0xffffc9000001f738)
    at drivers/pci/msi/api.c:268
#13 0xffffffff82039d1f in vp_request_msix_vectors (
    vdev=vdev@entry=0xffff88800e86a000, nvectors=5, 
    per_vq_vectors=per_vq_vectors@entry=true, desc=<optimized out>, 
    desc@entry=0xffffc9000001f738)
    at drivers/virtio/virtio_pci_common.c:160
#14 0xffffffff8203a615 in vp_find_vqs_msix (
    vdev=vdev@entry=0xffff88800e86a000, nvqs=nvqs@entry=4, 
    vqs=vqs@entry=0xffff88800d739ac0, 
    vqs_info=vqs_info@entry=0xffff88800d761100, 
    vector_policy=vector_policy@entry=VP_VQ_VECTOR_POLICY_EACH, 
    desc=desc@entry=0xffffc9000001f738)
    at drivers/virtio/virtio_pci_common.c:417
#15 0xffffffff8203ac0a in vp_find_vqs (vdev=vdev@entry=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@entry=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@entry=0xffff88800e86a098, 
    drv=drv@entry=0xffffffff840a5020 <virtio_blk>)
    at drivers/base/dd.c:581
#22 0xffffffff82115038 in really_probe (dev=dev@entry=0xffff88800e86a098, 
    drv=drv@entry=0xffffffff840a5020 <virtio_blk>)
    at drivers/base/dd.c:659
#23 0xffffffff821153d9 in __driver_probe_device (
    drv=drv@entry=0xffffffff840a5020 <virtio_blk>, 
    dev=dev@entry=0xffff88800e86a098)
    at drivers/base/dd.c:801
#24 0xffffffff8211590a in driver_probe_device (
    drv=drv@entry=0xffffffff840a5020 <virtio_blk>, 
    dev=dev@entry=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@entry=0x0, data=data@entry=0xffffffff840a5020 <virtio_blk>, 
    fn=fn@entry=0xffffffff82115b30 <__driver_attach>)
    at drivers/base/bus.c:383
#27 0xffffffff82114738 in driver_attach (
    drv=drv@entry=0xffffffff840a5020 <virtio_blk>)
    at drivers/base/dd.c:1243
#28 0xffffffff82113860 in bus_add_driver (
    drv=drv@entry=0xffffffff840a5020 <virtio_blk>)
    at drivers/base/bus.c:715
#29 0xffffffff821171f6 in driver_register (
    drv=drv@entry=0xffffffff840a5020 <virtio_blk>)
    at drivers/base/driver.c:249
#30 0xffffffff8202306b in __register_virtio_driver (
    driver=driver@entry=0xffffffff840a5020 <virtio_blk>, owner=owner@entry=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


  reply	other threads:[~2026-01-09 19:13 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-10-24  2:30 [PATCH] lib/group_cpus: make group CPU cluster aware Wangyang Guo
2025-12-21 19:10 ` Andrew Morton
2025-12-22  3:03   ` Guo, Wangyang
2026-01-09 19:13     ` Radu Rendec [this message]
2026-01-09 22:47       ` Andrew Morton
2026-01-13  2:37         ` Guo, Wangyang
2026-01-10  2:24       ` Guo, Wangyang
2026-01-13  1:59         ` Guo, Wangyang

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=b4a61e3d17db7666a2b523fc57fdbb9356eb5191.camel@redhat.com \
    --to=rrendec@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=dan.liang@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tglx@linutronix.de \
    --cc=tianyou.li@intel.com \
    --cc=tim.c.chen@linux.intel.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