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/
This archive was generated by hypermail 2b29 : Thu Mar 23 2000 - 21:00:24 EST