KS2007: Memory management & application notification of low memory
KS2007: Memory management & application notification of low memory
Posted Sep 13, 2007 22:07 UTC (Thu) by oak (guest, #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).
Posted Sep 13, 2007 22:30 UTC (Thu)
by nix (subscriber, #2304)
[Link] (2 responses)
(This is new behaviour in glibc 2.5.)
Posted Sep 16, 2007 19:43 UTC (Sun)
by oak (guest, #2786)
[Link] (1 responses)
Can you still limit that to be smaller with MALLOC_MMAP_THRESHOLD_
However, in some environments and with some applications, the memory
Posted Sep 16, 2007 23:11 UTC (Sun)
by nix (subscriber, #2304)
[Link]
The glibc mmap threshold *minimum* is 128Kb. In recent versions of glibc KS2007: Memory management & application notification of low memory
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.)
> The glibc mmap threshold *minimum* is 128Kb. In recent versions of glibc KS2007: Memory management & application notification of low memory
the threshold is dynamically adjusted [...] (This is new behaviour in
glibc 2.5.)
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/...
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
MALLOC_MMAP_THRESHOLD_ still works: it's precisely equivalent to calling KS2007: Memory management & application notification of low memory
mallopt (M_MMAP_THRESHOLD, ...); setting any of these mmap parameters
disables dynamic adjustment completely.