Re: [PATCH] do not place remainders into fastbins

["Carlos O'Donell" <carlos at redhat dot com>]

On 06/06/2013 11:54 AM, Michal Schmidt wrote:
> While working with a program that reads many short strings using
> sscanf(..., "%ms", &s), I noticed it used more memory than I had
> expected. sscanf starts by allocating 100 bytes, and later
> reallocs to the exact size. It resulted in a heap layout like this:
>  +-------+------------------+-------+------------------+-------+---
>  |string1|       free       |string2|       free       |string3| ...
>  +-------+------------------+-------+------------------+-------+---
> 
> When testing with fastbins disabled (by setting M_MXFAST to 0),
> the resulting heap was nicely condensed instead (and obviously smaller).

Interesting! Thanks for working this out.

> I cannot say it's definitely a bug, but IMHO it would be better not to
> create fastbins in this testcase. The reasoning goes:
> 
> When freeing a chunk that was just created as a remainder from
> a shrinking realloc etc., there is no reason to expect that the
> application will later malloc chunks of this exact size.
> Thus placing the chunk in fastbin is not likely to be helpful.
> 
> Let's avoid placing remaindered chunks in fastbins.

Why?

With what data do you back up your expectations or claims?

Have you done any whole system benchmarking to show that this
yields any performance gain?

Have you done any whole system benchmarking to show that this
yields a decrease in memory pressure?

Have you considered adding a microbenchmark for this to the
glibc bench tests to show it has no performance impact?

> Note: I have not signed the FSF copyright Assignment, but I do not
> consider this change to be legally significant.

Just to clarify, what's important are the GNU guidelines:
http://www.gnu.org/prep/maintain/maintain.html#Legally-Significant

However, your employer (and mine) has a blanket assignment for all
FSF projects, so copyright for your patch is not in question.

Cheers,
Carlos.