From: "DERUMIER, Alexandre" <alexandre.derumier@groupe-cyllene.com>
To: "pve-devel@lists.proxmox.com" <pve-devel@lists.proxmox.com>,
"f.ebner@proxmox.com" <f.ebner@proxmox.com>
Subject: Re: [pve-devel] qemu + tcmalloc for rbd
Date: Wed, 10 Jan 2024 09:38:42 +0000 [thread overview]
Message-ID: <2f04e8bd5c67726fecb4cba19c5f6bb728837bdc.camel@groupe-cyllene.com> (raw)
In-Reply-To: <2668369e-0ace-4826-a443-6c6834adfa14@proxmox.com>
Hi Fiona, (and happy new year)
> Currently, In production, I compile qemu with tcmalloc at build.
>
> This patch serie, allow to do use LD_PRELOAD + disable malloc_trim()
> call in qemu.
>
> I'm not expert in C (I re-used code from haproxy, which is doing
> exactly the same thing with tcmalloc && trim).
> So if somebody can review it, it could be great :)
>
>>Unfortunately, the QEMU patch seems rather hacky and I'd prefer to
>>not
>>include and maintain it. If tcmalloc would just provide malloc_trim()
>>(e.g. as a no-op), there would be no need for the ugly
>>at-runtime-detection at all.
ok no problem.
Note that I don't remember to to have seen problem with a simple
LD_preload, even if qemu is calling malloc_trim().
But It's was only benchmark, and not production.
ceph guys also have benchmark it with LD_preload here:
https://ceph.io/en/news/blog/2022/qemu-kvm-tuning/
>
> Another way (maybe safer), is to build 2 binary in same package
> (/usr/bin/kvm-tcmalloc && /usr/bin/kvm), and give option to user to
> choose it.
>
>>If we go for this route, I'd rather have two conflicting packages to
>>avoid the redundant space usage for most people. Or if we really want
>>to
>>support being able to use both on a single system, an add-on kind of
>>package with just the second binary.
Personnaly, I'm fine with 2 packages.
pve-qemu && pve-qemu-tcmalloc for example.
with in pakckage control
Provides: pve-qemu
Conflicts: pve-qemu
Replaces: pve-qemu
?
>>For reference, since it's been a while, previous discussion:
>>https://lists.proxmox.com/pipermail/pve-devel/2023-March/056129.html
>>
>>Maybe you'd also like to ping the upstream enhancement request for
>>glibc?
>>https://sourceware.org/bugzilla/show_bug.cgi?id=28050
yes, good idea. (I don't have munch hope about this ^_^ )
next prev parent reply other threads:[~2024-01-10 9:39 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-09 17:02 DERUMIER, Alexandre
2024-01-10 9:12 ` Fiona Ebner
2024-01-10 9:38 ` DERUMIER, Alexandre [this message]
2024-01-10 14:53 ` Thomas Lamprecht
2024-01-10 10:15 ` Thomas Lamprecht
2024-01-10 18:29 ` 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=2f04e8bd5c67726fecb4cba19c5f6bb728837bdc.camel@groupe-cyllene.com \
--to=alexandre.derumier@groupe-cyllene.com \
--cc=f.ebner@proxmox.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