PING [patch] malloc: add mxfast tunable

[Carlos O'Donell]

On 8/8/19 5:36 PM, Florian Weimer wrote:
> * Carlos O'Donell:
> 
>> 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?
> 
> With 16 byte alignment, we have possible chunk sizes 16, 32, 48, 64, 80.
> 
>> 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)
> 
> These sizes result in fastbin indices 0, 2, 4, 6, 8.  The odd indices
> are unused, I think.

Yes, you are absolutely right, we should change the shifting to be
based on MALLOC_ALIGNMENT to get this right. Please file a bug for that.

-- 
Cheers,
Carlos.