[lkml]   [2000]   [Jul]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Kernel 2.2.14 OOM killer strikes.
On Thu, 06 Jul 2000, Derek Martin wrote:
>On Thu, 6 Jul 2000, Marcelo Tosatti wrote:
>> If the kernel does not kill some processes (or one process) when the
>> system is under OOM, probably all the system will lockup because there is
>> no memory and no more swap space left. Your chance to start a shell and
>> kill the memory hog is gone.
>> Now _which_ process(es) the kernel should choose to kill is a different
>> issue.
>Doesn't it make the most sense to kill the process that caused the OOM?
>That seems the most logical thing to me...

And just how do you suggest that be done?

The current process requesting a memory page? - what if it is init (boom,,
reboot). What if it is inetd... or syslog (trying to get a buffer for the
OOM message :)... Any non-root process ? what if it is a simple telnet
attack (hundreds of telnet connections... no logins, just lots of telnetd
daemons...) or the web server (same situation, although some do a better
job of not exceeding limits).

This has been covered several times over the last two years. It will not
go away until there is resource accounting, and user resource accounting
enforcement implemented. That is being worked on, and will get better when
the VM changes stablize.

There is a patch in the mailing list archives for 2.2 (14?) that was a
demonstration of some limits - the system was set to not allow users to exceed
90% (or so) of the memory resources. Root didn't have limits. This patch does
not work for 2.3/2.4 kernels. It even had the option to disable the limit
enforcement (current limit) enforce limit on user, enforce limit on user and
root. The patch doesn't fix everything, but does cover about 80% of the

Jesse I Pollard, II

Any opinions expressed are solely my own.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:57    [W:0.197 / U:30.456 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site