Re: VM Problems in 2.6.7 (Too active OOM Killer)

From: Bill Davidsen
Date: Mon Jul 19 2004 - 15:20:25 EST

William Lee Irwin III wrote:
On Wed, 2004-07-14 at 15:44, Andrew Morton wrote:

If the kernel has no swap there is nothing it can do with an anonymous page
(ie: the thing whcih malloc() gives you). It is effectively pinned memory,
because there's nowhere we can write it to get rid of it.

On Wed, Jul 14, 2004 at 05:30:52PM -0700, Peter Zaitsev wrote:

Why can't it be moved to other zone if there is a lot of place where ?
In general I was not pushing system in some kind of stress mode - There
was still a lot of cache memory available. Why it could not be instead
shrunk to accommodate allocation ?

The only method the kernel now has to relocate userspace memory is IO.
When mlocked, or if anonymous when there's no swap, it's pinned.

On Wed, Jul 14, 2004 at 05:30:52PM -0700, Peter Zaitsev wrote:

As I understand in my case with 4G there is Normal zone and HighMem
zone where "user" anonymous memory can be located in any of these zones.
Is this observation correct ?


On Wed, 2004-07-14 at 15:44, Andrew Morton wrote:

If you end up pinning all of your ZONE_NORMAL pages with anonymous memory,
further GFP_KERNEL allocation attempts will go oom.

On Wed, Jul 14, 2004 at 05:30:52PM -0700, Peter Zaitsev wrote:

Aha I see. So user level memory allocations can't cause OOM only kernel
level allocations can ? In this case why do not you have some reserved
amount of space for these types of allocations by default ?

Userspace allocations can also trigger OOM, it's merely that in this
case only allocations restricted to ZONE_NORMAL or below, e.g. kernel
allocations, are affected. Your memory pressure is restricted to one zone.

On Wed, Jul 14, 2004 at 05:30:52PM -0700, Peter Zaitsev wrote:

In this case I also do not understand how swap space helps here ? If you
can't move page to over zone or shrink cache because of allocation type
how it happens you can however perform page swap ?

In order to relocate a userspace page, the kernel performs IO to write
the page to some backing store, then lazily faults it back in later. When
the userspace page lacks a backing store, e.g. anonymous pages on
swapless systems, Linux does not now understand how to relocate them.

Can you briefly explain why the obvious method of moving a page from point A to point B, both in physical memory, can't be used? Or even the less obvious marking of some physical memory as swap space.

Clearly if this was as easy as it looks it would have been done, I just don't quite follow why it isn't easy.

And on a related topic, there was a way in 2.4 kernels to designate part of physical memory as swap. It was really useful if you had one of those 386 chipsets which could only cache 64MB, and more memory than that. It was long ago enough that I can't remember if that was a feature or a patch. Actually so long ago it could have been 2.2.xx on that machine, I just booted it an ran it for years.

-bill davidsen (davidsen@xxxxxxx)
"The secret to procrastination is to put things off until the
last possible moment - but no longer" -me
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at