On 19/09/17 20:47, Paolo Bonzini wrote: > On 19/09/2017 12:39, Alexey Kardashevskiy wrote: >>> No, there's still >>> >>> as->dispatch = NULL; >>> memory_region_update_pending |= root->enabled; >>> memory_region_transaction_commit(); >>> >>> when creating the address space, which touches all address spaces. >> >> This does not seem helping a lot - my test without such an optimization >> allocates 2966044 FVs and 2388768 with it, which is just 25%, i.e. worth >> making a patch but yet getting rid of those nasty virtio-modern address >> spaces will do a lot better job. > > Have you tried resolving aliases that are implemented with containers > and one subregion?
Yes, for 10 virtio-net and 8 cpus it looks like below, #5 is that shared thing. And if I use Intel e1000 instead, it is just 4 FVs. (qemu) info mtree -f -d FlatView #0 AS "virtio-pci-cfg-as", root: virtio-pci-cfg, alias virtio-pci Root memory region: virtio-pci FlatView #1 AS "I/O", root: io Root memory region: io FlatView #2 AS "pci@800000020000000", root: pci@800000020000000.iommu-root Root memory region: pci@800000020000000.iommu-root FlatView #3 AS "virtio-pci-cfg-as", root: virtio-pci-cfg, alias virtio-pci Root memory region: virtio-pci FlatView #4 AS "virtio-pci-cfg-as", root: virtio-pci-cfg, alias virtio-pci Root memory region: virtio-pci FlatView #5 AS "virtio-net-pci", root: bus master container AS "virtio-net-pci", root: bus master container AS "virtio-net-pci", root: bus master container AS "virtio-net-pci", root: bus master container AS "virtio-net-pci", root: bus master container AS "virtio-net-pci", root: bus master container AS "virtio-net-pci", root: bus master container AS "virtio-net-pci", root: bus master container AS "virtio-net-pci", root: bus master container AS "virtio-net-pci", root: bus master container Root memory region: (none) No rendered FlatView FlatView #6 AS "virtio-pci-cfg-as", root: virtio-pci-cfg, alias virtio-pci Root memory region: virtio-pci FlatView #7 AS "virtio-pci-cfg-as", root: virtio-pci-cfg, alias virtio-pci Root memory region: virtio-pci FlatView #8 AS "virtio-pci-cfg-as", root: virtio-pci-cfg, alias virtio-pci Root memory region: virtio-pci FlatView #9 AS "virtio-pci-cfg-as", root: virtio-pci-cfg, alias virtio-pci Root memory region: virtio-pci FlatView #10 AS "virtio-pci-cfg-as", root: virtio-pci-cfg, alias virtio-pci Root memory region: virtio-pci FlatView #11 AS "memory", root: system AS "cpu-memory", root: system AS "cpu-memory", root: system AS "cpu-memory", root: system AS "cpu-memory", root: system AS "cpu-memory", root: system AS "cpu-memory", root: system AS "cpu-memory", root: system AS "cpu-memory", root: system Root memory region: system FlatView #12 AS "virtio-pci-cfg-as", root: virtio-pci-cfg, alias virtio-pci Root memory region: virtio-pci FlatView #13 AS "virtio-pci-cfg-as", root: virtio-pci-cfg, alias virtio-pci Root memory region: virtio-pci >> What is the exact concern about the "[PATCH qemu v3 01/13] memory: Postpone >> flatview and dispatch tree building till all devices are added"? Is it that >> you missed that modern AS thing in virtio and thought we can do well even >> without it? > > I am afraid that some of the special sysbus devices (not PCI, those go > through the bus master DMA region and it's empty on startup) might write > to memory during initialization. And somehow QEMU guarantees that all RAM MRs are rendered to FlatViews even though some might be added via -device (can they btw?)? > > Thanks, > > Paolo > >> Or there is something wrong with the approach? > -- Alexey
