Hi, On 2023-06-26 08:38:35 +0200, Ronan Dunklau wrote: > I hope what I'm trying to achieve is clearer that way. Maybe this patch is not > the best way to go about this, but since the memory allocator behaviour can > have such an impact it's a bit sad we have to leave half the performance on > the table because of it when there are easily accessible knobs to avoid it.
I'm *quite* doubtful this patch is the way to go. If we want to more tightly control memory allocation patterns, because we have more information than glibc, we should do that, rather than try to nudge glibc's malloc in random direction. In contrast a generic malloc() implementation we can have much more information about memory lifetimes etc due to memory contexts. We e.g. could keep a larger number of memory blocks reserved ourselves. Possibly by delaying the release of additionally held blocks until we have been idle for a few seconds or such. WRT to the difference in TPS in the benchmark you mention - I suspect that we are doing something bad that needs to be improved regardless of the underlying memory allocator implementation. Due to the lack of detailed instructions I couldn't reproduce the results immediately. Greetings, Andres Freund