Re: echo 0 > /proc/sys/vm/swappiness triggers OOM killer under 2.6.14.

[Rob Landley]

On Wednesday 02 November 2005 01:32, Dave Jones wrote:
> On Tue, Nov 01, 2005 at 02:37:01AM -0600, Rob Landley wrote:
>  > oom-killer: gfp_mask=0x400d2, order=0
>
> something explicitly asked for a highmem page.
>
>  > 0 pages of HIGHMEM
>
> You don't have any.
>
> Calling the oom-killer in this situation seems drastic though.
>
>   Dave

Except that the only difference between this test and the one that succeeds is 
the value of "/proc/sys/vm/swappiness".  With 60 it finishes, with 0 it 
fails.  The same binaries are being run by the same script, and in neither 
case is there highmem in the kernel.

The test system is a User Mode Linux instance, running a shell script in place 
of init.  As a result, there are very few processes running in this system, 
and only one is really active at a time.

At the failure point, the shell script calls the "make" of gcc 4.0.2, and far 
and away the high point of memory usage is gcc's "genattrtab", which creates 
and then compiles a .c file that causes the system to swap for about 5 
minutes before it completes.  (This is an extreme memory hog: Before I 
started feeding UML a swap file, it couldn't complete with only 128 megs of 
ram, but finished with 256.  Now I'm telling UML mem=64M and attaching a 256 
megabyte file to the Usermode Block Device driver, to act as a swap 
partition.)

So at the point of failure, bash is blocked waiting on a child, make is 
blocked waiting on a child, gcc is building its attrtab pig, and nothing else 
(no daemons, not even init) is running on the system.  It's a pretty 
straightforward "the VM goes nuts in a low memory situation" case.

If you'd like to reproduce this, I can send you my build script.  It's 
self-contained, downloads all  the source code it needs automatically, and 
either succeeds or reproduces the problem quite deterministically depending 
on whether or not the "echo 0 > /proc/sys/vm/swappiness" line is present or 
not.

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