[pve-devel] qemu + tcmalloc for rbd

[DERUMIER, Alexandre]

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 ^_^ )