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

["DERUMIER, Alexandre" <alexandre.derumier@groupe-cyllene.com>]

Am 10/01/2024 um 10:12 schrieb Fiona Ebner:
> Am 09.01.24 um 18:02 schrieb DERUMIER, Alexandre:
> > 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.

>>I would like to avoid both, an extra package or an extra binary, as
>>both are a significant overhead for both us to maintain and user to
>>work with.
>>
>>Either tcmalloc works as allocator and is an actual improvement
>>overall,
>>in which case we should unconditionally use it, or it doesn't work,
>>or is
>>no improvement, in which case it makes no sense to expose it.

Yes, I totally understand that. If user have problems (maybe not
related to allocator), it'll need to all tests x2 to debug
(iothreads,..).

>>IME changing allocator is nice for some specific benchmarks, but
>>overall
>>there often even are some regressions in other configurations..

Personnaly, I really see a big difference on real workload with
latencies. (where latencies is really where ceph can be slow)

>>We e.g. tested different allocators extensively when debugging some
>>memory growth during PBS backups, none of the shiny alternatives was
>>really any better, thus we resulted to triggering explicit trims.

yes, I remember of that.  I don't use PBS, so I can't comment about
this.

Do you have more information about how to reproduce this ? 
I could take some test tcmalloc again with pbs backups.