[Gllug] mallinfo

Nix nix at esperi.org.uk
Tue Oct 30 21:04:23 UTC 2007


On 30 Oct 2007, tethys at gmail.com stated:

> On 10/30/07, t.clarke <tim at seacon.co.uk> wrote:
>
>> Any suggestions (or do I have a buggy glib ?)
>
> You're making assumptions about how malloc(3) is implemented. So while
> traditional Unix may use sbrk(2) to get its memory, Linux uses mmap(2)
> instead.

`As well', not `instead.'

The rule used to be simple: allocations of over a certain size
(customizable, defaulting to 128Kb) would use mmap(). These days, the
rule is more complex: allocations of over a certain size still use
mmap(), but if you free memory allocated via the mmap() scheme, the
threshold goes up (with an upper bound of 32Mb for 32-bit boxes and
64Mb for 64-bit boxes).

The idea is to have transient allocations generally use brk()ed storage,
so the kernel doesn't have to zero the space over and over again.

(It also uses different algorithms for small allocations <64 bytes than
it does for allocations larger than that: the very small ones are tuned
for speed over space on the ground that they are likely to be very
frequent.)

The 32Mb allocation used by the original poster is *way* over the
default mmap threshold, and nothing's getting freed, so it's all
going to be mmap()ed, as you suggest.

> Oh, and K&R style arguments to main()? ANSI/ISO style arguments have
> been around for nearly 20 years now...

Hear hear.

-- 
`Some people don't think performance issues are "real bugs", and I think 
such people shouldn't be allowed to program.' --- Linus Torvalds
-- 
Gllug mailing list  -  Gllug at gllug.org.uk
http://lists.gllug.org.uk/mailman/listinfo/gllug




More information about the GLLUG mailing list