Linux PCI subsystem development
 help / color / mirror / Atom feed
From: Pavol Sakac <sakacpav@amazon.de>
To: Bjorn Helgaas <bhelgaas@google.com>
Cc: linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org,
	"David Matlack" <dmatlack@google.com>,
	"Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>,
	"Krzysztof Wilczyński" <kwilczynski@kernel.org>,
	"Kees Cook" <kees@kernel.org>,
	"Madhavan Srinivasan" <maddy@linux.ibm.com>,
	"Michael Ellerman" <mpe@ellerman.id.au>,
	"Nicholas Piggin" <npiggin@gmail.com>,
	"Christophe Leroy" <chleroy@kernel.org>,
	linuxppc-dev@lists.ozlabs.org,
	"Niklas Schnelle" <schnelle@linux.ibm.com>,
	"Benjamin Block" <bblock@linux.ibm.com>,
	"Lukas Wunner" <lukas@wunner.de>,
	"Ionut Nechita" <ionut.nechita@windriver.com>,
	nh-open-source@amazon.com
Subject: [RFC PATCH 0/8] PCI/IOV: Initialize virtual functions in parallel
Date: Fri, 11 Sep 2026 14:11:13 +0200	[thread overview]
Message-ID: <20260911-vfopt-s1-v1-0-693271dc0226@amazon.de> (raw)

In the context of kexec-based live update (LUO) used with
datacenter-level hardware for hosting virtualized instances, once
SR-IOV enablement is put in the hot path it becomes a downtime
bottleneck on modern hardware with 100s-1000s of VFs per PF, and begs
for optimization.

This series (S1) introduces parallel VF initialization to put stress on
all participating subsystems; the 4 subsequent series then attack and
optimize the serialization bottlenecks one by one, with the primary
objective of reducing initialization time to a minimum.

On real hardware - a large dual-socket arm64 Neoverse V2 server with
thousands of VFs - the five series together cut SR-IOV initialization
by 65%. Due to HW/SW combination, the iommu_probe_device_lock residual
is not present. This series alone accounts for less than 5% of that,
so the reduction comes from the four series that follow removing the
serialization that keeps the parallelism from paying off.

Lock statistics and SR-IOV init time for 4x PF (NVMe, 255 VFs each)
enabled serially, using the public reproducer described below:

  lock_stat:
  Lock                     wait: Before     After   contentions: Before   After
  iommu_probe_device_lock          0 ms  25507 ms                     0    1143
  &root->kernfs_rwsem             18 ms    942 ms                  3117   93208
  &vfio.group_lock                 0 ms    425 ms                     0     497

  Stage                 SR-IOV init time:
  S0 (baseline)         3027 ms
  S1 (this series)       999 ms

Reproducer:

Runs an x86_64 QEMU/KVM guest with all PCI config space accesses routed
through ECAM, avoiding pci_config_lock, which otherwise serializes the
legacy port-I/O (0xCF8/0xCFC) accesses used for config offsets below
0x100. Guest topology: 48 vCPUs (2 sockets x 24 cores, one thread per
core, pinned 1:1 to host physical cores) and 2 NUMA nodes. After boot it
enables SR-IOV on 4 PFs sequentially (sriov_numvfs, 255 VFs each) and
measures init time on a kernel built without CONFIG_LOCK_STAT, then
separately collects /proc/lock_stat data on a kernel built with
CONFIG_LOCK_STAT=y.

In all series, I lean primarily on lock_stat numbers to defend the
improvements. In the reproducer, the residual iommu_probe_device_lock
dominates the window and masks the later series' wall-time gains;
reducing that lock further is out of scope for this set, but the
dominant residual source is named in S2 and can be followed up in the
future.

Looking for feedback on the overall design shape of the optimizations.

The full set of series building on top of this one:
- S2 iommu_probe_device_lock optimization:
  https://lore.kernel.org/r/20260911-vfopt-s2-v1-0-fff3db7e01c2@amazon.de
- S3 driver core: cut per-node lock traffic in bulk device
  registration (kernfs_rwsem write-taken once per node instead of
  twice, batched inode IDs, indexed glue dirs):
  https://lore.kernel.org/r/20260911-vfopt-s3-v1-0-66e3602f76f7@amazon.de
- S4 vfio: create the group chardev outside vfio.group_lock,
  eliminating its contention:
  https://lore.kernel.org/r/20260911-vfopt-s4-v1-0-98ba1d2ef7ab@amazon.de
- S5 remove the kernfs_rwsem bottleneck by staged sysfs registration:
  an opted-in device's whole subtree is published in one write hold
  instead of one per node:
  https://lore.kernel.org/r/20260911-vfopt-s5-v1-0-fa4cacdb6ca8@amazon.de

This set of series replaces a previous attempt to optimize VF init:
https://lore.kernel.org/lkml/20260702174033.32116-1-sakacpav@amazon.de/

The reproducer is available as a docker image that orchestrates
builds in a QEMU guest and prints results as a table (x86_64 Linux
host with /dev/kvm assumed):

  docker run --device /dev/kvm ghcr.io/pavsa/linux-parallel-sriov-vf-init-bench:7.3-base

Pavol Sakac (8):
  PCI/IOV: Split virtfn bus handling out of pci_iov_add_virtfn()
  PCI/IOV: Create virtfn buses up front in sriov_add_vfs()
  PCI/PM: Convert pci_bridge_d3_update() recursion to iteration
  PCI/PM: Serialize pci_bridge_d3_update()
  powerpc/pci: Serialize pcibios_bus_add_device()
  PCI/IOV: Let sriov_add_vfs() own the failure unwind
  PCI/IOV: Initialize virtual functions in parallel
  PCI: Probe inline from node-local workqueue workers

 arch/powerpc/kernel/pci-common.c |  14 ++-
 drivers/pci/iov.c                | 189 +++++++++++++++++++++++++++----
 drivers/pci/pci-driver.c         |  18 ++-
 drivers/pci/pci.c                |  87 +++++++++-----
 4 files changed, 252 insertions(+), 56 deletions(-)


base-commit: cee9395acd8043be0644b25c34bfa86623f2b935
-- 
2.47.3


             reply	other threads:[~2026-09-11 12:11 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-11 12:11 Pavol Sakac [this message]
2026-09-11 12:28 ` [RFC PATCH 1/8] PCI/IOV: Split virtfn bus handling out of pci_iov_add_virtfn() Pavol Sakac
2026-09-11 12:45   ` sashiko-bot
2026-09-11 12:29 ` [RFC PATCH 2/8] PCI/IOV: Create virtfn buses up front in sriov_add_vfs() Pavol Sakac
2026-09-11 12:46   ` sashiko-bot
2026-09-11 12:29 ` [RFC PATCH 3/8] PCI/PM: Convert pci_bridge_d3_update() recursion to iteration Pavol Sakac
2026-09-11 12:40   ` sashiko-bot
2026-09-11 12:30 ` [RFC PATCH 4/8] PCI/PM: Serialize pci_bridge_d3_update() Pavol Sakac
2026-09-11 12:47   ` sashiko-bot
2026-09-11 12:31 ` [RFC PATCH 5/8] powerpc/pci: Serialize pcibios_bus_add_device() Pavol Sakac
2026-09-11 12:55   ` sashiko-bot
2026-09-11 12:32 ` [RFC PATCH 6/8] PCI/IOV: Let sriov_add_vfs() own the failure unwind Pavol Sakac
2026-09-11 12:52   ` sashiko-bot
2026-09-11 12:33 ` [RFC PATCH 7/8] PCI/IOV: Initialize virtual functions in parallel Pavol Sakac
2026-09-11 12:43   ` sashiko-bot
2026-09-11 12:34 ` [RFC PATCH 8/8] PCI: Probe inline from node-local workqueue workers Pavol Sakac
2026-09-11 12:40   ` sashiko-bot

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=20260911-vfopt-s1-v1-0-693271dc0226@amazon.de \
    --to=sakacpav@amazon.de \
    --cc=bblock@linux.ibm.com \
    --cc=bhelgaas@google.com \
    --cc=chleroy@kernel.org \
    --cc=dmatlack@google.com \
    --cc=ilpo.jarvinen@linux.intel.com \
    --cc=ionut.nechita@windriver.com \
    --cc=kees@kernel.org \
    --cc=kwilczynski@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=lukas@wunner.de \
    --cc=maddy@linux.ibm.com \
    --cc=mpe@ellerman.id.au \
    --cc=nh-open-source@amazon.com \
    --cc=npiggin@gmail.com \
    --cc=schnelle@linux.ibm.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