From: Dietmar Maurer <dietmar@proxmox.com>
To: Proxmox Backup Server development discussion
<pbs-devel@lists.proxmox.com>,
Stefan Reiter <s.reiter@proxmox.com>
Subject: Re: [pbs-devel] [PATCH proxmox-backup-restore-image 4/4] add workaround kernel patch for vsock panics
Date: Tue, 27 Apr 2021 08:13:33 +0200 (CEST) [thread overview]
Message-ID: <222936624.518.1619504013059@webmail.proxmox.com> (raw)
Answering myself, after talking with Thomas:
> On 04/26/2021 8:04 PM Dietmar Maurer <dietmar@proxmox.com> 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 <s.reiter@proxmox.com> 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 <s.reiter@proxmox.com>
> > ---
> > .../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 <s.reiter@proxmox.com>
> > +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/
next reply other threads:[~2021-04-27 6:14 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-27 6:13 Dietmar Maurer [this message]
-- strict thread matches above, loose matches on Subject: below --
2021-04-26 18:04 Dietmar Maurer
2021-04-26 13:04 [pbs-devel] [PATCH proxmox-backup 1/4] file-restore: add size to image files and components Stefan Reiter
2021-04-26 13:04 ` [pbs-devel] [PATCH proxmox-backup-restore-image 4/4] add workaround kernel patch for vsock panics Stefan Reiter
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=222936624.518.1619504013059@webmail.proxmox.com \
--to=dietmar@proxmox.com \
--cc=pbs-devel@lists.proxmox.com \
--cc=s.reiter@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