[Patch] Memory allocation fixes (was: Re: konqy preloading kills performance)

[Germain Garand]

Le Vendredi 17 Décembre 2004 12:34, Koos Vriezen a écrit :
> On Wed, Dec 15, 2004 at 08:51:29AM +0000, Germain Garand wrote:
>
> > 2) enforces the FREELIST_MAX limit. It currently is not and would happily
> > use as many gigabytes as you'd throw it, without ever freeing them.
>
> I don't follow you here. There is a 'freelist_count >= FREELIST_MAX'
> check. And if this call doesn't work, next one will?

it might yes, but in a lot of cases it would be to late, because the freelist 
would only become full _after_ a more-than-average page has been unloaded.

If that more-than-average page happens to be of the kind of the MySQL 
documentation, the entire pool will be linked to the global freelist, so you 
are stuck with a 100 Mb+ global freelist until process exit.

>
> > 3) introduces a change of memory allocation strategy for heavy pages:
> > over a given threshold, increase the pool sizes so that malloc gets a
> > chance to give some ressources back to the OS (mostly via munmapping,
> > though trimming is also more likely to happen with large chunks).
>
> So if cumul becomes > 2Mb, it starts allocating pages with minsize of
> 80kb (instead of 4kb). 

yes, thank you for clearing that, I should have explained it in more details 
;(

> Are you sure it would help, ie. why not start with
> larger pages in the first place?

Yes, it does help (at least for glibc 2.x on a system with mmap support so 
I'll assume in the below that it is ifdef'ed that way, to be safe).

The rationale is that with a low memory load (for a given pool), you are 
better off with small chunks that will most probably be allocated in the 
faster way via sbrk and won't reserve more than needed.

Whereas, if the current trend is to allocate vast amounts for a single pool, 
mmap is more adequate, and the memory will be handled back to the system 
straight after, so better pass over the threshold where it will be used as 
fast as possible.
Also, there is a limit to the number of mmap a process can do, so that's why I 
tried a 4% fractional parameter and not a fixed one. It could be limited to a 
maximum amount.

If this sounds too dangerous, I'll just drop the idea. I probably will unless 
it receives some kind of blessing. Maybe mmaping directly then as you 
suggest.

About the initial 4kb threshold : I will try to raise it to something like 
max(8192, 2*pagesize ) to reduce the space lost by fragmentation. I just 
checked the Apache Portable Runtime memory pools and they use 8192 as the 
smaller value, so it might work well. Will benchmark that.

> Have you done some benchmarking here?

I couldn't measure any significant difference in time on a global page 
rendering with and without the patch (timing on the MySQL documentation and 
some 16Mb HTML of mine). This is glibc 2.3.1 on a 2.4.21 linux kernel. Shame 
on me.

Anyway, thanks for your input... I plan to commit 1) and 2) and think about 
the rest.

Greetings,
Germain