User: Password:
Subscribe / Log in / New account

Avoiding the OOM killer with mem_notify

Avoiding the OOM killer with mem_notify

Posted Feb 7, 2008 16:04 UTC (Thu) by ringerc (subscriber, #3071)
Parent article: Avoiding the OOM killer with mem_notify

As a (fairly bad) application developer I'm not sure I understand how I can use this

Say I'm notified that the kernel is running low on RAM. Furthermore, say I have a 265MB block
- a single allocation - and a bunch of small heap allocations before and after it in the heap.
Assuming I can afford to throw away the 256MB allocation I can delete() or free() it; however,
since I have more memory both higher and lower in the heap I don't see how the OS can reclaim
the RAM. I presume it relies on the huge allocation being a separate memory mapping (where
anonymous mmap() has been used by operator new or by malloc() ) that can be unmapped as per

So ... what about if my cache is a tree of heap-allocated objects of variable sizes (say, a
tree of polymorphic subtype instances)? Free()ing these objects is unlikely to help, since
many pages will have other things allocated on them too, and in any case the OS has no way to
know if a given page is free. This is especially likely when using the libstdc++ new(), which
(I understand) internally pre-allocates chunks of memory and parcels them out without invoking
lower level memory manegement. My understanding was that in this case all the kernel can do is
swap out the inactive page(s). I presume that to benefit from mem_notify I'd need to modify
the application to perform single large allocations dedicated only to use for this particular
cache, presumably either managing it with a C++ allocator interface (with the STL/Boost/etc)
or manually manage allocations within the block?

We all know it's often cleaner to use a container or an allocator in C++ when you want to
manage lots of small allocations of a particular type (especially when each is a fixed size
but they happen at unpredictable times) ... but many people don't, and in fact don't
understand them at all. It doesn't help that the STL and core language provide absolutely no
flexible pool allocators etc; you have to go to Boost for those, and many OSS / Free Software
projects are strangely reluctant to add a dependency on Boost.

What might help would be if there was a tiny portable C/C++ library (suitable to be compiled
directly into apps) that provided entirely standard and highly portable routines for non-Linux
platforms, and on Linux provided mem-pressure-aware C++ allocators and C memory allocation
calls + notifier callback hooks. All with identical interfaces, of course, though the
non-Linux ones would never actually detect and respond to memory pressure (unless other
platform support was added). A set of C++ "cache allocators" for various usage patterns that
could monitor memory pressure and automatically notify interested parties then invalidate and
release themselves would be particularly cool.

Craig Ringer

(Log in to post comments)

Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds