Messages in this thread | | | Date | Wed, 27 Sep 2000 18:13:34 +0800 | From | Andrey Savochkin <> | Subject | Re: the new VMt |
| |
Hello,
On Tue, Sep 26, 2000 at 01:10:30PM +0100, Mark Hemment wrote: > > On Mon, 25 Sep 2000, Stephen C. Tweedie wrote: > > So you have run out of physical memory --- what do you do about it? > > Why let the system get into the state where it is neccessary to kill a > process? > Per-user/task resource counters should prevent unprivileged users from > soaking up too many resources. That is the DoS protection. > [snip] > It is possible to do true, system wide, resource counting of physical > memory and swap space, and to deny a fork() or mmap() which would cause > over committing of memoy resources if everyone cashed in their > requirements. [snip]
People use overcommitting not because they are fans of the idea. Overcommitting simply is the _efficient_ way of resource sharing. It's a waste of resources to reserve memory+swap for the case that every running process decides to modify libc code (and, thus, should receive its private copy of the pages). A real waste! I always agree to take the risk of some applications being killed in such a case of all processes turning crazy.
The approach I believe in is: - ensure that accidental or intentional madness of applications of one user may cause only limited damage to other users; and - introduce a way to tell the kernel that some applications should be saved longer than others when troubles begin and ways to set up some guaranteed amounts for important processes. Certainly, a lot of processes may consume more than their guarantee until bad things start to happen. Then the rules of user protection and killing order apply. That's how I develop the resource control in the beancounter patch ftp://ftp.sw.com.sg/pub/Linux/people/saw/kernel/user_beancounter/UserBeancounter.html#s7
Best regards Andrey - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
| |