svn commit: r325965 - head/libexec/rtld-elf

[Edward Tomasz Napierała]

On 1119T1040, Pedro Giffuni wrote:
> 
> 
> On 11/19/17 07:12, Edward Tomasz Napierala wrote:
> > On 1118T1610, Konstantin Belousov wrote:
> >> On Sat, Nov 18, 2017 at 01:21:22PM +0000, Edward Tomasz Napierala wrote:
> >>> Author: trasz
> >>> Date: Sat Nov 18 13:21:22 2017
> >>> New Revision: 325965
> >>> URL: https://svnweb.freebsd.org/changeset/base/325965
> >>>
> >>> Log:
> >>>    Increase rtld initial memory pool size from 32kB to 128kB.
> >>>    
> >>>    The old value was probably fine back in 1998, when that code was imported
> >>>    (although the comments still mention VAX, which was quite obsolete by then);
> >>>    now, however, it's too small to handle our libc, which results in some
> >>>    additional calls to munmap/mmap later on.  Asking for more virtual address
> >>>    space is virtually free, and syscalls are not, thus the change.
> >>>    
> >>>    It was suggested by kib@ that this might be a symptom of a deeper problem.
> >>>    It doesn't only affect libc, though - the change also improves rtld memory
> >>>    management for eg KDE libraries.  I guess it's just a natural bloat.
> >> This is not what I said.
> >>
> >> My guess was that the large allocation you see in the ktrace output as
> >> coming from rtld was really an allocation of the TLS segment, and it was
> >> so large because libc has that large TLS segment. You did not checked this
> >> guess against the actual code.
> > Right, I stand corrected.
> >
> >> If my guess is true, I do not see a point in the change you made:  the
> >> memory consumption is externally imposed on rtld, and we should not try
> >> to tailor it to single, whenever important, consumer.
> > Here's where I disagree.  The rtld is not some abstract concept, it's one
> > of the components of the operating system, and it can and should be tweaked
> > to match real life situations.  Especially when it affects virtually all
> > of its use cases, as is the case with libc.
> >
> >
> 
> Being pragmatic ...
> 
> Determining such values is almost always a trial-and-error process. 
> Perhaps 64k is makes everyone (especially KDE) happy?

It was determined by trial and error.  128k is the smallest one that removes
the need for addidional call to mmap on startup - not for KDE, but for every
binary linked with libc, including true(1).  Running kdeinit4 still results
in a few such calls - although fewer than before (the value also affects the
size of subsequent rtld allocations).