Re: Larger GC thresholds for non-interactive Emacs

[Eli Zaretskii]

> From: Ihor Radchenko <yantar92@gmail.com>
> Cc: Lars Ingebrigtsen <larsi@gnus.org>,  Mattias Engdegård
>  <mattiase@acm.org>,  Eli Zaretskii <eliz@gnu.org>,  Tim Cross
>  <theophilusx@gmail.com>,  rms@gnu.org,  Alan Mackenzie <acm@muc.de>,
>   emacs-devel <emacs-devel@gnu.org>
> Date: Sat, 25 Jun 2022 13:13:22 +0800
> 
> > Not at all.  The general rule of thumb is: the sooner you recover free
> > space, the better you can avoid fragmentation.
> 
> Sure. But how does the probability to get fragmentation scale with the
> GC threshold? Is it linear scaling or is it nonlinear (I suspect that it
> is non-linear)? Can someone quantify it? If we do, it would help to
> adjust the thresholds more optimally to balance between GC time and
> fragmentation.

The answer depends on the C library being used.  If you are talking
about glibc, there's still the question of the statistics of
allocation size distribution, because AFAIK glibc's malloc
implementation uses several separate lists to manage the arena, each
list for allocations between X and Y bytes, where X and Y are
different for each list.  And for allocations larger than 64KB we
instruct glibc to use mmap, where there should be no fragmentation at
all.