From: Fiona Ebner <f.ebner@proxmox.com>
To: Proxmox VE development discussion <pve-devel@lists.proxmox.com>,
Alexandre Derumier <aderumier@odiso.com>
Subject: Re: [pve-devel] [PATCH v4 qemu-server 15/16] memory: virtio-mem : implement redispatch retry.
Date: Wed, 22 Feb 2023 16:19:55 +0100 [thread overview]
Message-ID: <8edb8da5-04b4-ed25-c56f-9626a2ee259f@proxmox.com> (raw)
In-Reply-To: <20230213120021.3783742-16-aderumier@odiso.com>
Am 13.02.23 um 13:00 schrieb Alexandre Derumier:
> If some memory can be removed on a specific node,
> we try to rebalance again on other nodes
>
> Signed-off-by: Alexandre Derumier <aderumier@odiso.com>
> ---
> PVE/QemuServer/Memory.pm | 51 +++++++++++++++++++++++++++-------------
> 1 file changed, 35 insertions(+), 16 deletions(-)
>
> diff --git a/PVE/QemuServer/Memory.pm b/PVE/QemuServer/Memory.pm
> index bf4e92a..f02b4e0 100644
> --- a/PVE/QemuServer/Memory.pm
> +++ b/PVE/QemuServer/Memory.pm
> @@ -201,13 +201,28 @@ my sub get_virtiomem_total_current_size {
> return $size;
> }
>
> +my sub get_virtiomem_total_errors_size {
> + my ($mems) = @_;
> +
> + my $size = 0;
> + for my $mem (values %$mems) {
> + next if !$mem->{error};
> + $size += $mem->{current};
> + }
> + return $size;
> +}
> +
> my sub balance_virtiomem {
> my ($vmid, $virtiomems, $blocksize, $target_total) = @_;
>
> - my $nb_virtiomem = scalar(keys %$virtiomems);
> + my $nb_virtiomem = scalar(grep { !$_->{error} } values $virtiomems->%*);
>
> print"try to balance memory on $nb_virtiomem virtiomems\n";
>
> + die "No more available blocks in virtiomem to balance all requested memory\n"
> + if $target_total < 0;
I fee like this message is a bit confusing. This can only happen on
unplug, right? And reading that "no more blocks are available" sounds
like a paradox then. It's rather that no more blocks can be unplugged.
If we really want to, if the $target_total is negative, we could set it
to 0 (best to do it at the call-side already) and try to unplug
everything else? We won't reach the goal anymore, but we could still get
closer to it in some cases. Would need a bit more adaptation to avoid an
endless loop: we also need to stop if all devices reached their current
goal this round (and no new errors appeared), e.g. balance_virtiomem()
could just have that info as its return value.
Example:
> update VM 101: -memory 4100,max=65536,virtio=1
> try to balance memory on 2 virtiomems
> virtiomem0: set-requested-size : 0
> virtiomem1: set-requested-size : 4
> virtiomem1: last: 4 current: 4 target: 4
> virtiomem1: completed
> virtiomem0: last: 16 current: 16 target: 0
> virtiomem0: increase retry: 0
> virtiomem0: last: 16 current: 16 target: 0
> virtiomem0: increase retry: 1
> virtiomem0: last: 16 current: 16 target: 0
> virtiomem0: increase retry: 2
> virtiomem0: last: 16 current: 16 target: 0
> virtiomem0: increase retry: 3
> virtiomem0: last: 16 current: 16 target: 0
> virtiomem0: increase retry: 4
> virtiomem0: last: 16 current: 16 target: 0
> virtiomem0: too many retry. set error
> virtiomem0: increase retry: 5
Currently it stops here, but with setting $target_total = 0 it continues...
> try to balance memory on 1 virtiomems
> virtiomem1: set-requested-size : 0
> virtiomem1: last: 4 current: 0 target: 0
> virtiomem1: completed
...and gets closer to the goal...
> try to balance memory on 1 virtiomems
> virtiomem1: set-requested-size : 0
> virtiomem1: last: 4 current: 0 target: 0
> virtiomem1: completed
> try to balance memory on 1 virtiomems
> virtiomem1: set-requested-size : 0
> virtiomem1: last: 4 current: 0 target: 0
> virtiomem1: completed
...but then it loops, because I didn't add the other stop condition yet
;). But not sure, likely too much magic.
> + die "No more available virtiomem to balance the remaining memory\n" if $nb_virtiomem == 0;
"No more virtiomem devices left to try to ..." might be a bit clearer.
Technically, they are still available, we just ignore them because they
don't reach the target in time.
> +
> #if we can't share exactly the same amount, we add the remainder on last node
> my $target_aligned = int( $target_total / $nb_virtiomem / $blocksize) * $blocksize;
> my $target_remaining = $target_total - ($target_aligned * ($nb_virtiomem-1));
next prev parent reply other threads:[~2023-02-22 15:20 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-13 12:00 [pve-devel] [PATCH v4 qemu-server 00/16] rework memory hotplug + virtiomem Alexandre Derumier
2023-02-13 12:00 ` [pve-devel] [PATCH v4 qemu-server 01/16] memory: extract some code to their own sub for mocking Alexandre Derumier
2023-02-13 12:00 ` [pve-devel] [PATCH v4 qemu-server 02/16] tests: add memory tests Alexandre Derumier
2023-02-13 12:00 ` [pve-devel] [PATCH v4 qemu-server 03/16] memory: refactor sockets Alexandre Derumier
2023-02-13 12:00 ` [pve-devel] [PATCH v4 qemu-server 04/16] memory: remove calls to parse_hotplug_features Alexandre Derumier
2023-02-13 12:00 ` [pve-devel] [PATCH v4 qemu-server 05/16] add memory parser Alexandre Derumier
2023-02-13 12:00 ` [pve-devel] [PATCH v4 qemu-server 06/16] memory: add get_static_mem Alexandre Derumier
2023-02-13 12:00 ` [pve-devel] [PATCH v4 qemu-server 07/16] memory: use static_memory in foreach_dimm Alexandre Derumier
2023-02-13 12:00 ` [pve-devel] [PATCH v4 qemu-server 08/16] config: memory: add 'max' option Alexandre Derumier
2023-02-22 15:18 ` Fiona Ebner
2023-02-23 7:35 ` DERUMIER, Alexandre
2023-02-23 7:44 ` Fiona Ebner
2023-02-13 12:00 ` [pve-devel] [PATCH v4 qemu-server 09/16] memory: get_max_mem: use config memory max Alexandre Derumier
2023-02-22 15:19 ` Fiona Ebner
2023-02-13 12:00 ` [pve-devel] [PATCH v4 qemu-server 10/16] memory: rename qemu_dimm_list to qemu_memdevices_list Alexandre Derumier
2023-02-22 15:19 ` Fiona Ebner
2023-02-13 12:00 ` [pve-devel] [PATCH v4 qemu-server 11/16] memory: don't use foreach_reversedimm for unplug Alexandre Derumier
2023-02-22 15:19 ` Fiona Ebner
2023-02-23 8:38 ` DERUMIER, Alexandre
2023-02-13 12:00 ` [pve-devel] [PATCH v4 qemu-server 12/16] memory: use 64 slots && static dimm size when max is defined Alexandre Derumier
2023-02-13 12:00 ` [pve-devel] [PATCH v4 qemu-server 13/16] test: add memory-max tests Alexandre Derumier
2023-02-13 12:00 ` [pve-devel] [PATCH v4 qemu-server 14/16] memory: add virtio-mem support Alexandre Derumier
2023-02-22 15:19 ` Fiona Ebner
2023-02-13 12:00 ` [pve-devel] [PATCH v4 qemu-server 15/16] memory: virtio-mem : implement redispatch retry Alexandre Derumier
2023-02-22 15:19 ` Fiona Ebner [this message]
[not found] ` <00eab4f6356c760a55182497eb0ad0bac57bdcb4.camel@groupe-cyllene.com>
2023-02-24 7:12 ` Fiona Ebner
2023-02-13 12:00 ` [pve-devel] [PATCH v4 qemu-server 16/16] tests: add virtio-mem tests Alexandre Derumier
2023-02-15 13:42 ` [pve-devel] partially-applied: [PATCH v4 qemu-server 00/16] rework memory hotplug + virtiomem Fiona Ebner
2023-02-16 12:35 ` Fiona Ebner
2023-02-27 14:04 ` Thomas Lamprecht
2023-02-28 7:35 ` Fiona Ebner
2023-02-22 15:25 ` [pve-devel] " Fiona Ebner
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=8edb8da5-04b4-ed25-c56f-9626a2ee259f@proxmox.com \
--to=f.ebner@proxmox.com \
--cc=aderumier@odiso.com \
--cc=pve-devel@lists.proxmox.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