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

[Pedro Giffuni]

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?

Pedro.