On this machine (RH9, kernel 2.4.20-18.9) the docs say (in
/usr/src/linux-2.4/Documentation/vm/overcommit-accounting ):
-----------------
The Linux kernel supports four overcommit handling modes
0 - Heuristic overcommit handling. Obvious overcommits of address space are refused. Used for
atypical system. It ensures a seriously wild allocation fails while allowing overcommit to
reduceswap usage
1 - No overcommit handling. Appropriate for some scientific applications
2 - (NEW) strict overcommit. The total address space commit for the system is not permitted
toexceed swap + half ram. In almost all situations this means a process will not be killed
whileaccessing pages but only by malloc failures that are reported back by the kernel mmap/brk code.
3 - (NEW) paranoid overcommit The total address space commit for the system is not permitted
toexceed swap. The machine will never kill a process accessing pages it has mapped except
dueto a bug (ie report it!)
----------------------
So maybe
sysctl -w vm.overcommit_memory=3
is what's needed? I guess you might pay a performance hit for doing that,
though.
andrew
> > Yeah, I see it in the Mandrake kernel. But it's not in stock 2.4.19,
> > so you can't assume everybody has it.
> >
>
> We had this problem on a recent version of good old Slackware.
> I think we also had it on RedHat 8 or so.
>
> Doing this kind of killing is definitely a bad habit. I thought it had
> it had to do with something else so my proposal for pre-allocation
> seems to be pretty obsolete ;).
>
> Thanks a lot.
>
> Hans
