Messages in this thread | | | From | Jesse Pollard <> | Subject | Re: Overcommitable memory?? | Date | Sat, 18 Mar 2000 08:31:58 -0600 |
| |
On Fri, 17 Mar 2000, Rik van Riel wrote: >On Fri, 17 Mar 2000, Stephen C. Tweedie wrote: >> On Tue, 14 Mar 2000 14:32:49 -0300 (BRST), Rik van Riel >> <riel@conectiva.com.br> said: >> >> >> Without overcommit that just can not happen. There will be >> >> either a free page of memory or a free page of swap into which >> >> you can swap something else out. >> >> > Without overcommit it can still happen, unless you reserve one >> > page of swap space for every page of data that gets mmap()ed... >> >> Even that doesn't cure things. Think about stack growth. > >Exactly. > >I'd really like the non-overcommit fans to come up >with a good reason why a non-overcommitting system >doesn't suffer from the same problem, but all I've >seen so far are changes to the problem :) > >(and no, I don't believe there is any solution to >OOM on any system that allows userspace to dynamically >allocate memory ....)
As long as you remain within your resource quota limits... Using resource accounting and quota controls will prevent the SYSTEM from OOM conditions. Users (and processes) will get an Out-Of-Resource errors which the users can deal with. The system administrators and managemnt can analyze the resource accounting and determin where to assign/reassign allocations of a finite resource. In all cases, the system should not crash. System processes should not abort unless they are exceeding the resources allocated to them. User processes should not be able to cause random process aborts.
This also allows self recovery from some forms of DoS attacks. If telnetd recieves 1000 connections then it could exceed resource limits. inetd may die (or sendmail or...). With resource limits in place, at least inetd would be able to handle that - if say no more than 50 concurrent interactive logins were allowed, the other connections would be denied. The same goes for Apache which DOES do this. If the proper resource allocation were given then usrs running wild memory allocators would not be able to crash the system by causing init to die.
All else is a matter of implementation. ------------------------------------------------------------------------- Jesse I Pollard, II Email: pollard@cats-chateau.net
Any opinions expressed are solely my own.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |