Kernel memory allocation

Nikita Schmidt (
Sun, 11 May 1997 03:07:15 +0100


I wonder if there is a mechanism to prevent kernel from allocating all
the RAM. I suspect that may be the reason for the following problem:

When a process performs heavily overcommitting memory allocation, the
system eventually becomes unusable because of enormous swapping/paging.
This is not easily observable on 32 bit architectures, where a process'
virtual address space is limited to 4 Gb (it requires about 30 processes
to demonstrate the problem), while on 64 bit architectures a simple
wildly mallocing program (like enquire.c from gcc) will nicely do the

For example, a program that allocates about 3000 chunks of memory, 32 Mb
each, via malloc() on a 32 Mb RAM machine makes the system swap
endlessly even after having been stopped by Ctrl-Z. The system is
slightly useable for several seconds, until cron decides to run atrun.
`free' reports 256 kB free memory, about 1 Mb shared and cached. Almost
all processes are swapped out, including the offending program which
has about 24 Mb actually allocated memory by the moment, as malloc()
dirties one page (8K on an Alpha) per each chunk.

The same program with overcommitment prevented by memset() just sucks in
all the swap space (128 Mb) and ends up with `Out of memory', causing
no harm.

The whole thing looks like the kernel allocates all available RAM for
its structures which are not swappable, leaving just some kB for the
processes. Even though the memory-hungry program gets swapped out
(and a plenty of swap is still left unused), an extreme memory starvation
is observed.

Once the offending process is killed, everything immediately comes back
to norm. A huge amount (about 20 Mb) of real memory gets released
together with 25 Mb of swap space. The process' DSIZ is only 25 Mb
(as reported by ps), so those 20 Mb of RAM most probably do not belong
to any process, thus apparently being a kernel's property.

I think it may not be a bad idea to be careful when allocating
non-swappable pages. Although things like ulimit may work around the
problem in most cases, the last word should always be said by the kernel.

Or, may be, the actual reason is completely different?