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

From: Peter Zaitsev
Date: Wed Jul 14 2004 - 21:17:31 EST


On Wed, 2004-07-14 at 18:54, William Lee Irwin III wrote:

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

OK. So it is practically technical difficulty rather than fundamental
reason ? Why "move to other zone" way is not implemented ? It normally
should be cheaper than IO ?


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

Right. After being explained what without swap you have all pages pinned
it makes sense. On other hand why user Allocation will trigger OOM if
there are pages in other zone which still can be used ? Or are there any
restriction on this ?


>
> 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't it just be just (theoretically) moved to other zone with
appropriate system tables modifications ?

Well anyway it is good to hear "pinned anonymous" is only issue on
swapless systems. Together with the fact what 2.6 VM does not seems to
swap without a good reason as 2.4 one did, I perhaps can just have swap
file enabled.


--
Peter Zaitsev, Senior Support Engineer
MySQL AB, www.mysql.com



-
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/