PING [patch] malloc: add mxfast tunable
Carlos O'Donell
carlos@redhat.com
Thu Aug 8 21:24:00 GMT 2019
On 8/8/19 5:18 PM, Florian Weimer wrote:
> * Carlos O'Donell:
>
>> On 8/8/19 5:04 PM, Florian Weimer wrote:
>>> * DJ Delorie:
>>>
>>>>> +@deftp Tunable glibc.malloc.mxfast
>>>>> +One of the optimizations malloc uses is to maintain a series of ''fast
>>>>> +bins'' that hold chunks up to a specific size. The default and
>>>>> +maximum size which may be held this way is 80 bytes on 32-bit systems
>>>>> +or 160 bytes on 64-bit systems. Applications which value size over
>>>>> +speed may choose to reduce the number of fast bins with this tunable.
>>>>> +Note that the value specified includes malloc's internal overhead,
>>>>> +which is normally the size of one pointer, so add 4 on 32-bit systems
>>>>> +or 8 on 64-bit systems to the size passed to @code{malloc} for the
>>>>> +largest bin size to enable.
>>>>> +@end deftp
>>>
>>> I think the quotes are wrong, they should be `` '' (ASCII, Texinfo will
>>> transform them). Or you could use @dfn and add an index entry.
>>>
>>> Does the fastbin range depend on pointer or size or minimum malloc
>>> alignment? The latter is 16 bytes on some 32-bit architectures, even
>>> though it is usually 8 bytes.
>>
>> Entirely on SIZE_SZ.
>>
>> /* The maximum fastbin request size we support */
>> #define MAX_FAST_SIZE (80 * SIZE_SZ / 4)
>
> Huh. Doesn't this mean we have unused fastbins because there is never
> an allocation of the appropriate size to fill it?
The fastbin index code already offsets the first bins because they
are unindexable? Is that what you mean?
1571 /* offset 2 to use otherwise unindexable first 2 bins */
1572 #define fastbin_index(sz) \
1573 ((((unsigned int) (sz)) >> (SIZE_SZ == 8 ? 4 : 3)) - 2)
--
Cheers,
Carlos.
More information about the Libc-alpha
mailing list