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

[William Lee Irwin III]

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 ? 

Yes.


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.


-- wli
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/