Re: Fix for wrong OOM killer trigger?

From: Andrea Arcangeli
Date: Sat Sep 20 2003 - 09:35:09 EST


On Sat, Sep 20, 2003 at 01:09:28PM +0200, Roland Bless wrote:
> On Fri, Sep 19, 2003 at 09:25:44PM +0200, Andrea Arcangeli wrote:
> >
> > can you try with 2.4.22aa1? the oom killer there will only work on tasks
> > that are allocating memory, not on idle daemons, so the probability of
> > killing rsync first should be higher. stock SuSE 8.1 kernel should do
> > the same too.
>
> This will only help to avoid not shooting important daemons.
> The real cause, however, seems to be that the filesystem cache
> memory is not properly re-used when it should, or, that it tries to
> allocate a huge amount memory. The programs themselves do not
> allocate much memory! It must be the system, because I also
> ran programs with memory restrictions by ulimit. The programs
> are definitely not allocating the memory, and, 4GB RAM are really
> enough for a simple file server like ours.

that might be an accounting error in the oom killing then (even that
should be corrected in my tree or in the stock 8.1 SuSE kernel).

the reason normally oom accounting errors never showup, is that when the
amount of free-swap is >0, the oom-killer is never invoked (that's a
magic that probably avoids those situations to normally arise in the
stock kernel).

so maybe you had no swap, if you had no swap that would explain it.

and of course if you have 4G of ram and you know you've more than enough
ram then you'd be right using 0 swap (just the stock kernel oom killer
may malfunction, but that's not going to happen with the kernels I
suggested you to try, they'll be fine with 0 swap)

hope this helps ;)

Andrea - If you refuse to depend on closed software for a critical
part of your business, these links may be useful:
rsync.kernel.org::pub/scm/linux/kernel/bkcvs/linux-2.[45]/
http://www.cobite.com/cvsps/
svn://svn.kernel.org/linux-2.[46]/trunk
-
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/