On Tue, 17 Jun 2003, Sean Chittenden wrote:
> > > > For large allocations glibc tends to mmap() which does get
> > > > unmapped. There's a threshold of 4KB I think. Ofcourse,
> > > > thousands of allocations for a few bytes will never trigger it.
> > >
> > > But essentially all our allocation traffic goes through palloc,
> > > which bunches small allocations together. In typical scenarios
> > > malloc will only see requests of 8K or more, so we should be in
> > > good shape on this front.
> >
> > Ah, bad news. The threshold appears to be closer to 64-128KB, so for
> > small allocations normal brk() calls will be made until the third or
> > fourth expansion. This can be tuned (mallopt()) but that's probably
> > not too good an idea.
> [snip]
> > Not entirely sure if it will help at all. Obviously memory
> > fragmentation is your enemy here.
>
> Depending on data use constraints and the malloc() routine in use
> (this works with phk malloc() on FreeBSD, don't know about glibc or
> Slowaris' routines) there's a cute trick that you can do help with
> this scenario so that a large malloc()'ed region is at the end of the
> data segment and therefore a process can be sbrk()'ed and shrink when
> free() is called on the large allocated region.
Glibc allows malloc parameters to be tuned through environment variables.
Linux Journal had an article about tuning malloc in May's issue. The
article is available online at http://www.linuxjournal.com/article.php?sid=6390
--
Antti Haapala
