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

[Bill Davidsen <davidsen@tmr.com>]

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 ? 
> 
> 
> 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.

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@tmr.com)
"The secret to procrastination is to put things off until the
  last possible moment - but no longer"  -me