Re: [pve-devel] qemu + tcmalloc for rbd

[Thomas Lamprecht <t.lamprecht@proxmox.com>]

Am 10/01/2024 um 10:38 schrieb DERUMIER, Alexandre:
>>> 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.

Yeah, because LD_PRELOAD just overrides symbols, but does not
unload libraries or the like.

So when you LD_PRELOAD the tcmalloc.so it will load the malloc
related functions, but as it doesn't ship any malloc_trim()
function (symbol), the one from glibc (which is still present)
will be called, which is useless but probably not that much
extra work as the glibc malloc heap is rather empty anyway.

In the case one builds and links directly against tcmalloc
glibc's malloc is completely out of the picture, so that's why
QEMU added a conflict if both, any of the alternative malloc
implementations and the malloc-trim configure option is enabled.

If we want to expose this dynamically the qemu patch probably
wouldn't be required for above reason anyway (or we could just
ship our tcmalloc, or a separate object, that provides a no-op
malloc_trim() function symbol).