Messages in this thread |  | | Date | Wed, 26 Sep 2001 20:08:33 +0000 | From | José Luis Domingo López <> | Subject | Re: 2.4.10 much better than previous 2.4.x :-) |
| |
On Tuesday, 25 September 2001, at 20:35:15 -0400, Paul wrote:
> Rik van Riel <riel@conectiva.com.br>, on Mon Sep 24, 2001 [10:35:53 PM] said: > > > > If you have the time, could you also test 2.4.9-ac15 ? > > [...] > Im not complaining-- Im just curious why no OOM killing, > and the Mem stats report 337148k swap free (I have 337168k). > Does this memmory report look proper for a machine thrashing > itself to death from endless mallocs? > I've done several test with various versions of 2.4.x kernels, just to make sure OOM worked right or not. I've used setups with both swap and no swap, with swap double the RAM and equal to it, from a single user mode and full multiuser with tons of applications running.
To reach OOM I try one of two methods: first, the well-know glob() DoS (ls ../*/../*/../*/ etc), second, starting as many applications as I can, loading and creating huge images with gimp, etc.
In my test, OOM seems to work well most of the time, but not always. When in works, it works fine, that is, it doesn't kill applications too early, and (in recent kernel), multithreaded applications (like mozilla and staroffice) and fully wiped from memory ("old" 2.4.x kernels didn't kill all the threads, just the selected process ID).
When OOM doesn't work, the disk starts spinning like crazy, responsiveness in null, mouse doesn't move, consoles don't update, unability to switch to text consoles, etc. Giving time to the machine to recover itself is not helpful: after more than 15 minutes the disk continue to spin and sound like they were to inmediately crash :)
But in this situation, SysRq+K work fine most of the times: in a couple of seconds the disk stops its crazyness, and the machine recovers. The text console is unusable (can't display a thing), but issuing a "startx" blindly works as expected, as if nothing had happened.
I've tried playing with "freepages" tunnable (where it exists), to raise limits and (hopefully) keep more RAM free for the kernel for the hard times where it tries to recover from OOM. OOM still fails sometimes, but maybe I don't understand what freepages.[min|low|high] mean (having read documentation under linux/Documentation :)
-- José Luis Domingo López Linux Registered User #189436 Debian Linux Woody (P166 64 MB RAM) jdomingo EN internautas PUNTO org => ¿ Spam ? Atente a las consecuencias jdomingo AT internautas DOT org => Spam at your own risk
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |