From: Paolo Bonzini <pbonzini@redhat.com>
To: Alexey Kardashevskiy <aik@ozlabs.ru>, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH qemu v3 01/13] memory: Postpone flatview and dispatch tree building till all devices are added
Date: Tue, 19 Sep 2017 09:40:57 +0200 [thread overview]
Message-ID: <11f3ee38-7c70-41d8-0df1-774fbe95cfcb@redhat.com> (raw)
In-Reply-To: <a85cbaf9-d7c7-403b-2dfc-886f9ddc0920@ozlabs.ru>
On 19/09/2017 08:57, Alexey Kardashevskiy wrote:
>>> 3) you can consult the list (or hash table :)) of live FlatViews (which
>>> means you keep it live after memory_region_transaction_commit ends, and
>>> only clear it on the next call), and reuse an existing FlatView. Note
>>> that the number of distinct FlatViews should be very few,
>>
>> I keep missing this bit - why few? Each virtio-pci device creates 2 AS,
>> with proxy->modern_bar and pci_dev->bus_master_container_region which are
>> unique and not aliases. Remember, 500 virtio devices is my test case ;)
Argh, no, it's me who keeps missing the bit.
> More details: pci_dev->bus_master_container_region is a root and it is
> enabled but its only child pci_dev->bus_master_enable_region is not. Ok, in
> flatview_topology_update() I can render a FV, see that it is empty
> (view->nr==0) and share an empty FV in this case too, this halves the
> number of FVs (from ~1000 to ~500 for 500 virtio devices).
We can also resolve "fake" aliases, obtained through a region with only
one subregion.
> But proxy->modern_bar (which has an modern_cfg alias which is a root of an
> AS) is enabled since it is created and I could disable it and enable
> afterwards but since a PCI device enablement is done by writing to the
> config space, I kind of stuck here.
>
> I can do something like this and it helps a lot (now with -S I end up
> having 4 FVs and much better start time) but it is kinda hacky and "memory:
> Postpone flatview and dispatch tree building till all devices are added"
> solves this better imho, no?
I think modern_bar (actually modern_cfg) shouldn't have its own address
space, it's a pretty wasteful way to compute the dispatch tree where a
simple linked list or array would be enough:
memory-region: virtio-pci
00000000fe000000-00000000fe003fff (prio 1, i/o): virtio-pci
00000000fe000000-00000000fe000fff (prio 0, i/o): virtio-pci-common
00000000fe001000-00000000fe001fff (prio 0, i/o): virtio-pci-isr
00000000fe002000-00000000fe002fff (prio 0, i/o): virtio-pci-device
00000000fe003000-00000000fe003fff (prio 0, i/o): virtio-pci-notify
Paolo
next prev parent reply other threads:[~2017-09-19 7:41 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-18 10:16 [Qemu-devel] [PATCH qemu v3 00/13] memory: Reduce memory use Alexey Kardashevskiy
2017-09-18 10:16 ` [Qemu-devel] [PATCH qemu v3 01/13] memory: Postpone flatview and dispatch tree building till all devices are added Alexey Kardashevskiy
2017-09-18 14:54 ` Paolo Bonzini
2017-09-19 2:09 ` Alexey Kardashevskiy
2017-09-19 6:57 ` Alexey Kardashevskiy
2017-09-19 7:40 ` Paolo Bonzini [this message]
2017-09-19 7:57 ` Alexey Kardashevskiy
2017-09-19 7:59 ` Paolo Bonzini
2017-09-19 7:42 ` Paolo Bonzini
2017-09-19 10:39 ` Alexey Kardashevskiy
2017-09-19 10:47 ` Paolo Bonzini
2017-09-19 14:12 ` Alexey Kardashevskiy
2017-09-19 14:23 ` Paolo Bonzini
2017-09-18 10:16 ` [Qemu-devel] [PATCH qemu v3 02/13] exec: Explicitely export target AS from address_space_translate_internal Alexey Kardashevskiy
2017-09-18 14:28 ` Eric Blake
2017-09-19 0:15 ` Alexey Kardashevskiy
2017-09-18 10:16 ` [Qemu-devel] [PATCH qemu v3 03/13] memory: Open code FlatView rendering Alexey Kardashevskiy
2017-09-18 14:28 ` Eric Blake
2017-09-18 10:17 ` [Qemu-devel] [PATCH qemu v3 04/13] memory: Move FlatView allocation to a helper Alexey Kardashevskiy
2017-09-18 10:17 ` [Qemu-devel] [PATCH qemu v3 05/13] memory: Move AddressSpaceDispatch from AddressSpace to FlatView Alexey Kardashevskiy
2017-09-18 10:17 ` [Qemu-devel] [PATCH qemu v3 06/13] memory: Remove AddressSpace pointer from AddressSpaceDispatch Alexey Kardashevskiy
2017-09-18 10:17 ` [Qemu-devel] [PATCH qemu v3 07/13] memory: Switch memory from using AddressSpace to FlatView Alexey Kardashevskiy
2017-09-18 14:06 ` Alexey Kardashevskiy
2017-09-18 10:17 ` [Qemu-devel] [PATCH qemu v3 08/13] memory: Cleanup after switching " Alexey Kardashevskiy
2017-09-18 10:17 ` [Qemu-devel] [PATCH qemu v3 09/13] memory: Rename mem_begin/mem_commit/mem_add helpers Alexey Kardashevskiy
2017-09-18 10:17 ` [Qemu-devel] [PATCH qemu v3 10/13] memory: Store physical root MR in FlatView Alexey Kardashevskiy
2017-09-18 10:17 ` [Qemu-devel] [PATCH qemu v3 11/13] memory: Share FlatView's and dispatch trees between address spaces Alexey Kardashevskiy
2017-09-18 14:37 ` Paolo Bonzini
2017-09-18 10:17 ` [Qemu-devel] [PATCH qemu v3 12/13] memory: Get rid of address_space_init_shareable Alexey Kardashevskiy
2017-09-18 10:17 ` [Qemu-devel] [PATCH qemu v3 13/13] memory: Add flat views to HMP "info mtree" Alexey Kardashevskiy
2017-09-18 10:36 ` [Qemu-devel] [PATCH qemu v3 00/13] memory: Reduce memory use no-reply
2017-09-18 14:59 ` Paolo Bonzini
2017-09-19 0:19 ` Alexey Kardashevskiy
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=11f3ee38-7c70-41d8-0df1-774fbe95cfcb@redhat.com \
--to=pbonzini@redhat.com \
--cc=aik@ozlabs.ru \
--cc=qemu-devel@nongnu.org \
/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;
as well as URLs for NNTP newsgroup(s).