Re: [PATCH] realloc: Return unchanged if request is within usable size

[Aurelien Jarno <aurelien@aurel32.net>]

Hi,

On 2023-07-04 07:17, Siddhesh Poyarekar via Libc-alpha wrote:
> On 2023-07-03 18:02, Aurelien Jarno wrote:
> > This actually breaks the KDE Plasma Desktop, and more precisely
> > plasmashell when used with long configuration files [1] [2]. This commit
> > causes the virtual memory allocation to increase from ~2GB to ~11GB in
> > my testcase, while the resident memory basically stays stable. In turns
> > this prevent the clone syscall to work with the default kernel
> > overcommit configuration.
> > 
> > At this stage, I haven't identified the allocation pattern nor the
> > corresponding code in plasmashell.
> 
> I had dismissed this in a recent bug report[1] but I'm obviously wrong. I
> think I could make this conditional on usable - bytes being within 2 *
> SIZE_T for heap allocations (thus only catering for expansions) and within
> trim_threshold for mmap'd allocations to reduce the fragmentation.

Just another datapoint that can be helpful: setting
glibc.malloc.trim_threshold to 128K (the initial value, but fixed) also
workarounds the issue. So it seems the issue is a combination of the
dynamic adjustment of trim_threshold and this change to realloc.

> > Besides tweaking the configuration files, possible workarounds are
> > defining the glibc.malloc.trim_threshold GLIBC tunable to a low value
> > (for instance 128) or changing the vm.overcommit_memory kernel
> > configuration to 1. I guess the latter doesn't work on 32-bit
> > architectures though.
> 
> Right, the trim_threshold change was what I had suggested, but if it's
> impacting more than the odd application, the default behaviour is
> problematic.  I'll try to post a fix today.

Great, thanks a lot.

Regards,
Aurelien

-- 
Aurelien Jarno                          GPG: 4096R/1DDD8C9B
aurelien@aurel32.net                     http://aurel32.net