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 a typical system. It
                ensures a seriously wild allocation fails while allowing
                overcommit to reduce swap usage

1       -       No overcommit handling. Appropriate for some scientific

2       -       (NEW) strict overcommit. The total address space commit
                for the system is not permitted to exceed swap + half ram.
                In almost all situations this means a process will not be
                killed while accessing 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 to exceed swap. The machine
                will never kill a process accessing pages it has mapped
                except due to 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,


> > 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

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

Reply via email to