From: Andrey Drobyshev <andrey.drobyshev@virtuozzo.com>
To: "Denis V. Lunev" <den@openvz.org>, svt-core@virtuozzo.com
Subject: Re: [PATCH hci-8.0 0/2] pci: batch memory transactions around mapping updates #VSTOR-129348
Date: Fri, 11 Sep 2026 13:56:20 +0300 [thread overview]
Message-ID: <41459048-8a8a-4cf0-83ec-db89432c6822@virtuozzo.com> (raw)
In-Reply-To: <20260910203243.2346410-1-den@openvz.org>
Ack
Applied to hci-8.0
On 9/10/26 11:32 PM, Denis V. Lunev wrote:
> Restoring a PCI device's config space remaps its BARs, updates the bridge
> windows when it is a bridge, and toggles the bus master region. Each of
> those ends a memory transaction of its own, and a transaction commit
> re-renders the flatviews it touches, at a cost which grows with the number
> of memory regions in the machine.
>
> So a machine with a rich PCIe topology pays that render many times over
> while an incoming migration stream is read, once or more per device, even
> though nothing between the steps looks at an address space.
>
> Both patches wrap an existing sequence in a single transaction. There is
> no new API and no behaviour a guest can observe: each transaction opens and
> closes inside the function that starts it, so nothing sees an intermediate
> state which was not already reachable. pci_bridge_update_mappings() has
> worked this way for the bridge windows for a long time; the first patch
> just makes pci_update_mappings() consistent with it.
>
> Measured on a Windows Server 2022 guest with 64 vCPUs and 65 pcie-root-ports,
> the non-iterable part of an incoming migration drops by about a third. The
> saving scales with the number of PCI devices, so it is small for a plain
> machine and large for the topologies which hurt today.
>
> Note that pci_update_mappings() is also reached from the runtime config
> write path, not only from migration. Several BAR moves in one config write
> now share a rebuild instead of taking one each, which is the same win in
> miniature and equally invisible to the guest.
>
> CC: Michael S. Tsirkin <mst@redhat.com>
> Signed-off-by: Denis V. Lunev <den@virtuozzo.com>
>
> Denis V. Lunev (2):
> pci: batch BAR remapping into one memory transaction #VSTOR-129348
> pci: load a device's config inside one memory transaction
> #VSTOR-129348
>
> hw/pci/pci.c | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
prev parent reply other threads:[~2026-09-11 10:56 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-10 20:32 Denis V. Lunev
2026-09-10 20:32 ` [PATCH hci-8.0 1/2] pci: batch BAR remapping into one memory transaction #VSTOR-129348 Denis V. Lunev
2026-09-10 20:32 ` [PATCH hci-8.0 2/2] pci: load a device's config inside " Denis V. Lunev
2026-09-11 10:56 ` Andrey Drobyshev [this message]
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=41459048-8a8a-4cf0-83ec-db89432c6822@virtuozzo.com \
--to=andrey.drobyshev@virtuozzo.com \
--cc=den@openvz.org \
--cc=svt-core@virtuozzo.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.