Re: kernel 2.6.13 - space not freed to kernel

[Nix <nix@esperi.org.uk>]

On 2 Sep 2005, linux-os@analogic.com murmured woefully:
> The usual malloc() never resets the break address or remaps memory
> because it is an expensive operation. This means that when new
> data space needs to be allocated, malloc() doesn't have to get
> anything from the kernel because it already has, probably, all
> that it needs.
> 
> The only way memory will be 'returned' is when your program
> calls exit() or otherwise ceases to exist.

This is wrong and has been wrong for a very long time (at least
throughout the glibc2 and libc5 eras).

As the comments at the top of
<http://sourceware.org/cgi-bin/cvsweb.cgi/libc/malloc/malloc.c?rev=1.148&content-type=text/x-cvsweb-markup&cvsroot=glibc>
make clear, and as even the malloc documentation in glibc
says in less detail, glibc malloc() suballocates the brk area
for small chunks only, and shrinks that area when possible;
for large allocations, it uses mmap(). In that situation,
the memory can indeed be freed immediately.

(Why can't malloc allocate suballocatable heaps out of mmap() space? Why
does it use the brk area at all? I hear some of the BSDs are doing this
already, it wouldn't complicate malloc() much that I can see and might
even simplify it in some areas... is it that this would break apps? If
so, those apps are already broken if they're relying on the brk area
being used for allocations, and are definitely far too fragile to
live... I might see if I can modify malloc appropriately and do some
benchmarking.)

-- 
`... published last year in a limited edition... In one of the
 great tragedies of publishing, it was not a limited enough edition
 and so I have read it.' --- James Nicoll
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/