KS2007: Memory management & application notification of low memory [LWN.net]

KS2007: Memory management & application notification of low memory

Posted Sep 13, 2007 22:07 UTC (Thu) by oak (subscriber, #2786)
In reply to: KS2007: Memory management & application notification of low memory by vomlehn
Parent article: KS2007: Memory management

I think in Nokia internet tablets there's a notification about low memory
situations to applications through system D-BUS broadcasts[1]. Delivering
information with D-BUS messages has obviously a latency issue if
application is gobbling memory very fast, but I guess it works acceptably.

[1]
https://stage.maemo.org/svn/maemo/projects/haf/trunk/libo...

Btw. I think for applications which keep large freeable memory caches i.e.
have a very active and complex memory allocation schemes, (Glibc) heap
fragmentation is at least as large problem as getting rid of their caches.
The caches should at least be large enough that their allocations have
been memory mapped (>= 128KB is the Glibc default) instead of coming from
heap and therefore they are returned back to system immediately when they
are freed, but with heap fragmentation you can only hope that allocation
re-ordering helps (after you've analyzed which allocations are the
problem).

(Log in to post comments)

KS2007: Memory management & application notification of low memory

Posted Sep 13, 2007 22:30 UTC (Thu) by nix (subscriber, #2304) [Link]

The glibc mmap threshold *minimum* is 128Kb. In recent versions of glibc
the threshold is dynamically adjusted between 128Kb and 512Kb (on 32-bit
boxes) and 64Mb (on 64-bit). (The mmap threshold starts at 128Kb and rises
whenever the application frees mmap()ed memory, so that transient
allocations tend to use brk() instead.)

(This is new behaviour in glibc 2.5.)

KS2007: Memory management & application notification of low memory

Posted Sep 16, 2007 19:43 UTC (Sun) by oak (subscriber, #2786) [Link]

> The glibc mmap threshold *minimum* is 128Kb. In recent versions of glibc
the threshold is dynamically adjusted [...] (This is new behaviour in
glibc 2.5.)

Can you still limit that to be smaller with MALLOC_MMAP_THRESHOLD_
environment variable? This would indicate that the limit just increases
and never decreases, regardless of the environment variable:
http://sources.redhat.com/cgi-bin/cvsweb.cgi/libc/malloc/...

However, in some environments and with some applications, the memory
fragmentation is actually worse problem than some performance decrease. If
a device (e.g. an embedded one where you cannot just add more RAM) runs
out of memory because of heap fragmentation, that's going to have much
more drastic effect on performance than e.g. threading scalability
mentioned here:
http://sourceware.org/bugzilla/show_bug.cgi?id=1541

KS2007: Memory management & application notification of low memory

Posted Sep 16, 2007 23:11 UTC (Sun) by nix (subscriber, #2304) [Link]

MALLOC_MMAP_THRESHOLD_ still works: it's precisely equivalent to calling
mallopt (M_MMAP_THRESHOLD, ...); setting any of these mmap parameters
disables dynamic adjustment completely.