[pve-devel] qemu + tcmalloc for rbd

DERUMIER, Alexandre alexandre.derumier at groupe-cyllene.com
Wed Jan 10 10:38:42 CET 2024

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
>>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:

> 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
>>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:
>>Maybe you'd also like to ping the upstream enhancement request for

yes, good idea. (I don't have munch hope about this ^_^ )

More information about the pve-devel mailing list