Memory management in Kernel 2.4.x
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 11 lines · H. Peter Anvin
Followup to: <[email protected]> By author: Alan Cox <[email protected]> In newsgroup: linux.dev.kernelQuoted 7 lines
On a -ac kernel with mode 2 or 3 set for overcommit you have to run out of kernel resources to hang the box. It won't go OOM because it can't. That wouldn't be a VM bug but a leak or poor handling of kernel allocations somewhere. Sadly the changes needed to do that (beancounter patch) were things Linus never accepted for 2.4
Quoted 5 lines
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.
Regards,
Andreas Hartmann
Quoted 4 lines · Andreas Hartmann
Quoted 3 lines
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.
Quoted 8 lines
Quoted 1 line
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
Quoted 6 lines · Alan Cox
Quoted 4 lines · Andreas Hartmann
Quoted 3 lines
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.
Quoted 8 lines
Quoted 3 lines
Quoted 1 line
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.
I don't know, if they properly handle out of memory errors. It have been X-programms. Logon wasn't able either with login nor with ssh from remote (sshd couldn't fork).
Quoted 1 line
No OOM kills occur.
That's definitly right.
Quoted 4 lines
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.
A process which doesn't need any more memory is running well. In consoles, on which I have been logged in, I could roll through the last commands without any problem - but I couldn't start a new process.
Quoted 2 lines
Also if an old program crashes, it frees memory so you have room for a new one.
The memory wich has been freed is eaten up from the malicious program. It's very easy to reproduce it with the program I linked to in my first posting.
Quoted 2 lines
With your fork bomb there is a likelyhood that a new fork will beat others to the memory.
That's it. And if there is a program running with such a malfunction the machine can't do anything more. If a hacker wants to block your machine, he can do it without beeing root.
Quoted 8 lines
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
Quoted 5 lines
Staff have a guaranteed 75% of memory
Students have a guaranteed 25% of memory but can take 50 if its thereAnd 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
I think, that's what would be best. Ressources are given to groups and they must work with. There isn't any more for them - the rest is for sysadmins to ensure that they always can successfully control the machine and can kill malicious processes. No external reachable daemon must be running in the sysadmin ressource-group.
I think it's something like ressource-management on IBM's S390.
Regards,
Andreas Hartmann