I have been doing some tests with the proposed patches for better
management of OOM (out of memory) under Linux and I'm posting the
results for my configuration.
First some definitions:
1) This is my first leak.c (leak, for this message)
----------------------------
#include <stdlib.h>
main()
{
while(1)
{
if( malloc(2048) == 0)
sleep(1);
}
}
----------------------------
2) This is the leak.c program posted by Andrea (aleak, for this message)
----------------------------
#include <stdlib.h>
main()
{
char *p[20];
int i, j;
for (j=0; j<20; j++)
{
p[j] = (char *) malloc(1000000);
}
for (;;)
for (j=0; j<20; j++)
{
for (i=0; i<1000000; i++)
p[j][i] = 0;
}
}
----------------------------
3) My configuration is:
Processor: P166
RAM: 64MB
SWAP: 48MB
libc5, linux 2.1.124, egcs release 1.0.3
All tests done from X, KDE 1.0
--------------------------------------------------------------
**************************************************************
**************************************************************
Testing linux 2.1.124 + Andrea's patch version 8
--------------------------------------------------------------
TEST 1
In this test I ran a few instances of aleak (4 to 6) and the system was
still responsive. However it seemed very near trashing.
Then I ran leak and still was able to switch from X to a text console.
The memory was totally full, I could not log in (can't map libxxx),
could not run free or any other program.
I switched back to X and the system was responsive for a while but went
into hard thashing soon. I let the system trashing for 15 minutes to see
what could happen and during this time I was unable to do anything
(switch VCs, mouse, CapsLock, NumLock, etc).
So, reset was the only option.
------------------------------------------------------------
TEST 2
In this test I ran 5 copies of aleak in backgound.
The system remained responsive for some minutes, I was able to run free
ps and other shell commands.
After some minutes I tried to run "ps -l" and the system echoed the
comand, but I waited aprox. 5 minutes and the command did not execute.
The system was no responsive and trashing.
Reset again
--------------------------------------------------
TEST 3
In this test I ran 5 copies of aleak in backgroud.
The behaviour was near the same as TEST 2. However after some minutes
trashing, my pograms started closing one after another. All xterms died,
KDE died, X died and I was returned to $ prompt. (I reported this same
behaviour with the first Andrea patch).
I was able to return to X and use the system without any problem.
------------------------------------------------------
Impressions:
I don't understand the result of TEST 3 (Andrea?)
For TESTs 1,2 it seems to me that the system behaves theoretically
perfect. It doesn't deadlock nor crash.
However this is not the behaviour I (the user) want, because I want
to be able to kill a/some process and get control of my system again.
In this state the system is out of control, because it has to swap
in/out
so many times that the execution of programs may take several
hundred years (am I right?) since the processor just execute some few
instructions and must wake up another process to execute some other few
instructions. (Please note that this paragraph is purely my opinion)
I have seen Andrea claim that his patch enhances Linux MM. I'm not able
to understand if its true, but I ask Rik to take a close look at it.
******************************************************
******************************************************
Testing linux 2.1.124 + Rick OOM Killer patch version 3
TESTS
I ran several copies of aleak and the kernel killed some when the system
was entering trashing.
Every time I ran leak, kernel killed it.
As already reported in the list, OOMKill v3 is not able to detect
correctly "when we are out of memory" so I'm unable to run netscape
because the kernel kills it.
I couldn't trash or crash the system with these leak programs.
-------------------------------------------------------------
Impressions:
Rik, when will we see version 4 with better OOM detection?
**************************************************************
And just to clarify, I'm supporting the idea that an OOM Killer must be
an option for people who need it and it seems that there are several
administrator out there who will be happier enabling it (me included).
Dino
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/