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
cases.
-- ------------------------------------------------------------------------- Jesse I Pollard, II Email: pollard@cats-chateau.netAny opinions expressed are solely my own.
- 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/
This archive was generated by hypermail 2b29 : Fri Jul 07 2000 - 21:00:20 EST