Re: Memory management in Kernel 2.4.x

[Alan Cox]

On Tue, 2002-05-28 at 06:42, Andreas Hartmann wrote:
> > Well, if you can't fork a new process because that would push you into
> > overcommit, then you usually can't actually do anything useful on the
> > machine.
> 
> >From my experience with mode 2:
> 
> you can't do _anything_, if the overcommitment range has been reached. Even 
> running programms are crashing if they want to have some more memory. So, 
> new processes cannot be started and old processes cannot run and are 
> crashing as far as they want to have more memory. At last, there will be 
> only one user-process on the machine running - the bad programm, eating up 
> all the memory.

Are you sure you have it properly configured. Programs will only crash
if they demand more memory and don't properly handle out of memory
errors. No OOM kills occur. I've run simulated sets with large databases
and I don't see the problem you are reporting. There is a not quite
theoretical case where everything continues running but nothing quits
because it all has the memory it wants and there is not enough more. 

Also if an old program crashes, it frees memory so you have room for a
new one. With your fork bomb there is a likelyhood that a new fork will
beat others to the memory. 

Ultimately something has to die off or give back resources when it finds
it can't get any. There is a finite resource, you used it all. Going
beyond the current stuff to doing definable chargable subgroups with per
subgroup resource billing and optional overcommit rules is doable (thats
beancounter stuff again) but does require we add setluid/getluid
syscalls, tweak the PAM code in user space and merge the beancounter
stuff. At that point you can do really *cool* stuff like

	Staff have a guaranteed 75% of memory
	Students have a guaranteed 25% of memory but can take 50 if its 		there

And sit contented in the sure knowledge that if you fire up emacs on a
giant file as a staff member you'll only kick students off the box

Alan