All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alexey Kardashevskiy <aik@ozlabs.ru>
To: Paolo Bonzini <pbonzini@redhat.com>, 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 12:09:32 +1000	[thread overview]
Message-ID: <2debed31-4c28-6dc3-b159-1fdc3fbf87f5@ozlabs.ru> (raw)
In-Reply-To: <c01622e7-3e6d-cf90-a28c-aa31b4857887@redhat.com>

On 19/09/17 00:54, Paolo Bonzini wrote:
> On 18/09/2017 12:16, Alexey Kardashevskiy wrote:
>> Most devices use at least one address space and every time a new address
>> space is added, flat views and dispatch trees are rebuild for all address
>> spaces. This is not a problem for a relatively small amount of devices but
>> even 50 virtio-pci devices use more than 8GB of RAM.
>>
>> What happens that on every flatview/dispatch rebuild, new arrays are
>> allocated and old ones release but the release is done via RCU so until
>> an entire machine is build, they are not released.
>>
>> This wraps devices creation into memory_region_transaction_begin/commit
>> to massively reduce amount of flat view/dispatch tree (re)allocations.
>>
>> Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
>> ---
>> Changes:
>> v2:
>> * wrapped qemu_run_machine_init_done_notifiers() as well
>> ---
>>  vl.c | 9 +++++++++
>>  1 file changed, 9 insertions(+)
>>
>> diff --git a/vl.c b/vl.c
>> index 9e62e92aea..e4f2ece590 100644
>> --- a/vl.c
>> +++ b/vl.c
>> @@ -4741,12 +4741,16 @@ int main(int argc, char **argv, char **envp)
>>      igd_gfx_passthru();
>>  
>>      /* init generic devices */
>> +    memory_region_transaction_begin();
>> +
>>      rom_set_order_override(FW_CFG_ORDER_OVERRIDE_DEVICE);
>>      if (qemu_opts_foreach(qemu_find_opts("device"),
>>                            device_init_func, NULL, NULL)) {
>>          exit(1);
>>      }
>>  
>> +    memory_region_transaction_commit();
>> +
>>      cpu_synchronize_all_post_init();
>>  
>>      rom_reset_order_override();
>> @@ -4829,8 +4833,13 @@ int main(int argc, char **argv, char **envp)
>>      /* TODO: once all bus devices are qdevified, this should be done
>>       * when bus is created by qdev.c */
>>      qemu_register_reset(qbus_reset_all_fn, sysbus_get_default());
>> +
>> +    memory_region_transaction_begin();
>> +
>>      qemu_run_machine_init_done_notifiers();
>>  
>> +    memory_region_transaction_commit();
>> +
>>      if (rom_check_and_register_reset() != 0) {
>>          error_report("rom check and register reset failed");
>>          exit(1);
>>
> 
> This should not be necessary given the other patches; the PCI devices
> have an empty address space at the beginning, so there are other less
> intrusive optimizations to do instead with the same effect:
> 
> 1) as a start, the "|= root->enabled" can resolve aliases.  This should
> be enough for the PCI device case.
> 
> 2) also, after patch 2 you know that the address space has no listeners
> here, so the begin/commit isn't really needed.  Instead you can use the
> open-coded loop to directly generate the FlatView.  This avoids touching
> _all_ address spaces, which is already an improvement from O(n^2) to
> O(n) rebuilds on device startup.
> 
> 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 ;)


> so feel free
> to revert from hash table to list in v4 if you prefer.
>> 4) you can skip address_space_update_topology_pass if
> QTAILQ_EMPTY(&as->listeners).  This can provide some startup speed
> improvements.
> 
> Optimizations 2/3/4 should be moved to the end of the series, or even in
> a separate post.  The first can be done in the beginning too, as you prefer.




-- 
Alexey

  reply	other threads:[~2017-09-19  2:09 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 [this message]
2017-09-19  6:57       ` Alexey Kardashevskiy
2017-09-19  7:40         ` Paolo Bonzini
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=2debed31-4c28-6dc3-b159-1fdc3fbf87f5@ozlabs.ru \
    --to=aik@ozlabs.ru \
    --cc=pbonzini@redhat.com \
    --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 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.