This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH 06/25] Add struct scratch_buffer and its internal helper functions
- From: Florian Weimer <fweimer at redhat dot com>
- To: OndÅej BÃlka <neleai at seznam dot cz>
- Cc: Paul Eggert <eggert at cs dot ucla dot edu>, libc-alpha at sourceware dot org
- Date: Wed, 08 Apr 2015 22:03:05 +0200
- Subject: Re: [PATCH 06/25] Add struct scratch_buffer and its internal helper functions
- Authentication-results: sourceware.org; auth=none
- References: <cover dot 1425285061 dot git dot fweimer at redhat dot com> <7a6fe503fb764beee3d5b89662d3bbf65242161c dot 1425285061 dot git dot fweimer at redhat dot com> <54F4BB15 dot 7070409 at cs dot ucla dot edu> <550C37F7 dot 10504 at redhat dot com> <20150403162531 dot GA25408 at domone>
On 04/03/2015 06:25 PM, OndÅej BÃlka wrote:
>> The original code used a growth factor of 3 during the alloca phase, and
>> 2 during the malloc phase. (After the i386 ABI change for stack
>> alignment, it's effectively 2 and 2.)
> That does not make much sense. Its mostly used in funcions that cannot
> realloc array themself so we double space until it fits. As its
> temporary its better to overallocate than try save space.
I suppose that could be true. There are two exceptions: When we cross
the trim threshold, and when we cross the mmap threshold. Both could be
quite bad performance-wise. I think we could come up with a sizing
strategy that avoids thatâor change NSS to allocate the buffer at the
point where the size is known (my preference).
However, it's true that it was more important to conserve space when the
code used alloca.
Thanks for your review of five of the other patches; I committed them
with suitable ChangeLog entries.
--
Florian Weimer / Red Hat Product Security