From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by lists.proxmox.com (Postfix) with ESMTPS id C08F977311 for ; Tue, 27 Apr 2021 08:14:07 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id B009B1BE65 for ; Tue, 27 Apr 2021 08:13:37 +0200 (CEST) Received: from proxmox-new.maurer-it.com (proxmox-new.maurer-it.com [94.136.29.106]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by firstgate.proxmox.com (Proxmox) with ESMTPS id B3C4A1BE56 for ; Tue, 27 Apr 2021 08:13:36 +0200 (CEST) Received: from proxmox-new.maurer-it.com (localhost.localdomain [127.0.0.1]) by proxmox-new.maurer-it.com (Proxmox) with ESMTP id 83C9041F66 for ; Tue, 27 Apr 2021 08:13:36 +0200 (CEST) Date: Tue, 27 Apr 2021 08:13:33 +0200 (CEST) From: Dietmar Maurer To: Proxmox Backup Server development discussion , Stefan Reiter Message-ID: <222936624.518.1619504013059@webmail.proxmox.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Priority: 3 Importance: Normal X-Mailer: Open-Xchange Mailer v7.10.5-Rev9 X-Originating-Client: open-xchange-appsuite X-SPAM-LEVEL: Spam detection results: 0 AWL 0.513 Adjusted score from AWL reputation of From: address KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record URIBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [github.io] Subject: Re: [pbs-devel] [PATCH proxmox-backup-restore-image 4/4] add workaround kernel patch for vsock panics X-BeenThere: pbs-devel@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox Backup Server development discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Apr 2021 06:14:07 -0000 Answering myself, after talking with Thomas: > On 04/26/2021 8:04 PM Dietmar Maurer wrote: > > > Such small buffer sizes can reduce performance. I usually go > for a minimum of 256K. > > So do we really need this? This is simply an optimization to reduce space usage. Performance is still good enough... > What is a 128 MiB RAM machine??? This is the restore VM ... > > > > On 04/26/2021 3:04 PM Stefan Reiter wrote: > > > > > > Allocation failures for vsock packet buffers occur routinely when > > downloading more than one stream at the same time, with less then 512 > > MiB of RAM it sometimes even occurs for single downloads. > > > > This appears to fix it in all of my reproducer scenarios, tested with up > > to 6 downloads at once in a 128 MiB RAM machine. > > > > Signed-off-by: Stefan Reiter > > --- > > .../0003-vsock-reduce-packet-size.patch | 36 +++++++++++++++++++ > > 1 file changed, 36 insertions(+) > > create mode 100644 src/patches/kernel/0003-vsock-reduce-packet-size.patch > > > > diff --git a/src/patches/kernel/0003-vsock-reduce-packet-size.patch b/src/patches/kernel/0003-vsock-reduce-packet-size.patch > > new file mode 100644 > > index 0000000..378da53 > > --- /dev/null > > +++ b/src/patches/kernel/0003-vsock-reduce-packet-size.patch > > @@ -0,0 +1,36 @@ > > +From a437d428733881f408b5d42eb75812600083cb75 Mon Sep 17 00:00:00 2001 > > +From: Stefan Reiter > > +Date: Mon, 26 Apr 2021 14:08:36 +0200 > > +Subject: [PATCH] vsock: reduce packet size > > + > > +Reduce the maximum packet size to avoid allocation errors in VMs with > > +very little memory available (since the buffer needs a contiguous > > +block of memory, which can get rare for 64kB blocks). > > + > > +4kB used to be the default, and according to [0] increasing it makes > > +the difference between ~25Gb/s and ~40Gb/s - certainly a lot faster, > > +but both within the realm of unreachable for our restore scenario. > > + > > +[0] https://stefano-garzarella.github.io/posts/2019-11-08-kvmforum-2019-vsock/