Messages in this thread | | | Date | Sat, 24 Mar 2001 12:38:01 +0000 | From | Jonathan Morton <> | Subject | Re: [PATCH] Prevent OOM from killing init |
| |
At 6:58 am +0000 24/3/2001, Rik van Riel wrote: >On Sat, 24 Mar 2001, Jonathan Morton wrote: > >> Hmm... "if ( freemem < (size_of_mallocing_process / 20) ) >>fail_to_allocate;" >> >> Seems like a reasonable soft limit - processes which have already got >> lots of RAM can probably stand not to have that little bit more and >> can be curbed more quickly. > >This looks like it could nicely in preventing a single process >from getting out of hand and gobbling up all memory. > >It won't prevent the system from a mongolian horde of processes, >but nobody should expect your one-liner to fix world piece ;) > >I like it, now lets test it ;)
I thought of some things which could break it, which I want to try and deal with before releasing a patch. Specifically, I want to make freepages.min sacrosanct, so that malloc() *never* tries to use it. This should be fairly easy to implement - simply subtract freepages.min from the freemem part. An even nicer way would be to subtract freepages.low (or some similar value) instead of freepages.min for non-root or non-privileged processes.
BTW, is the 'current' pointer always valid when vm_enough_memory() is called? If so, I can remove one redundant check.
My NetBSD friend appears to have found code in the BSD kernel which sets up ulimit values sensibly by default - eg. it's not handled by the boot scripts. Presumably a root process is capable of changing the limits, but I'm guessing that sensible defaults in the kernel have to be a Good Thing. Comments?
-------------------------------------------------------------- from: Jonathan "Chromatix" Morton mail: chromi@cyberspace.org (not for attachments) big-mail: chromatix@penguinpowered.com uni-mail: j.d.morton@lancaster.ac.uk
The key to knowledge is not to rely on people to teach you it.
Get VNC Server for Macintosh from http://www.chromatix.uklinux.net/vnc/
-----BEGIN GEEK CODE BLOCK----- Version 3.12 GCS$/E/S dpu(!) s:- a20 C+++ UL++ P L+++ E W+ N- o? K? w--- O-- M++$ V? PS PE- Y+ PGP++ t- 5- X- R !tv b++ DI+++ D G e+ h+ r++ y+(*) -----END GEEK CODE BLOCK-----
- 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/
| |