From: "DERUMIER, Alexandre" <Alexandre.DERUMIER@groupe-cyllene.com>
To: "pve-devel@lists.proxmox.com" <pve-devel@lists.proxmox.com>
Cc: "t.lamprecht@proxmox.com" <t.lamprecht@proxmox.com>
Subject: Re: [pve-devel] applied: [RFC pve-qemu] disable jemalloc
Date: Fri, 10 Mar 2023 18:05:29 +0000 [thread overview]
Message-ID: <5d774074596e5430faaa26146c70fdd13b513598.camel@groupe-cyllene.com> (raw)
In-Reply-To: <3dd51877-142c-55b2-e2ed-33f48ecb348f@proxmox.com>
Hi,
sorry for bumping this old thread.
I'm currently benching again qemu with librbd and memory allocator.
It's seem that they are still performance problem with default glibc
allocator, around 20-25% less iops and bigger latency.
From my bench, i'm around 60k iops vs 80-90k iops with 4k randread.
Redhat have also notice it
https://bugzilla.redhat.com/show_bug.cgi?id=1717414
https://sourceware.org/bugzilla/show_bug.cgi?id=28050
I known than jemalloc was buggy with rust lib && pbs block driver,
but did you have evaluated tcmalloc ?
Note that it's possible to load it dynamically with LD_PRELOAD,
so maybe could we add an option in vm config to enable it ?
Le mardi 15 décembre 2020 à 14:43 +0100, Thomas Lamprecht a écrit :
> On 10.12.20 16:23, Stefan Reiter wrote:
> > jemalloc does not play nice with our Rust library (proxmox-backup-
> > qemu),
> > specifically it never releases memory allocated from Rust to the
> > OS.
> > This leads to a problem with larger caches (e.g. for the PBS block
> > driver).
> >
> > It appears to be related to this GitHub issue:
> > https://github.com/jemalloc/jemalloc/issues/1398
> >
> > The background_thread solution seems weirdly hacky, so let's
> > disable
> > jemalloc entirely for now.
> >
> > Signed-off-by: Stefan Reiter <s.reiter@proxmox.com>
> > ---
> >
> > @Alexandre: you were the one to introduce jemalloc into our QEMU
> > builds a long
> > time ago - does it still provide a measurable benefit? If the
> > performance loss
> > would be too great in removing it, we could maybe figure out some
> > workarounds as
> > well.
> >
> > Its current behaviour does seem rather broken to me though...
> >
> > debian/rules | 1 -
> > 1 file changed, 1 deletion(-)
> >
> >
>
> applied, thanks!
>
>
> _______________________________________________
> pve-devel mailing list
> pve-devel@lists.proxmox.com
> https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
>
next prev parent reply other threads:[~2023-03-10 18:05 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-10 15:23 [pve-devel] " Stefan Reiter
2020-12-11 15:21 ` alexandre derumier
2020-12-15 13:43 ` [pve-devel] applied: " Thomas Lamprecht
2023-03-10 18:05 ` DERUMIER, Alexandre [this message]
2023-03-11 9:01 ` Thomas Lamprecht
[not found] <1c4d80a05d8328a52b9d15e991fd4d348bce1327.camel@groupe-cyllene.com>
2023-03-11 13:14 ` DERUMIER, Alexandre
2023-03-13 7:17 ` DERUMIER, Alexandre
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=5d774074596e5430faaa26146c70fdd13b513598.camel@groupe-cyllene.com \
--to=alexandre.derumier@groupe-cyllene.com \
--cc=pve-devel@lists.proxmox.com \
--cc=t.lamprecht@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 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.