This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: PING [patch] malloc: add mxfast tunable


* 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?

Thanks,
Florian


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]