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). _______________________________________________ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel