On Mon, 20 Mar 2000 09:51:46 -0600 (CST), you wrote:
>James Sutherland <jas88@cam.ac.uk>:
>> On Mon, 20 Mar 2000 09:31:29 +0100, you wrote:
>>
>> >> >catastrophic when it hits. It is much easier to write applications
>> >> >which are robust about memory allocation in a non-overcommit environment.
>> >>
>> >> Not really; remember, the stack is also demand-allocated.
>> >>
>> >Writing robust code isn't that hard - you know very well when a C
>> >program
>> >uses stack (function calls, local variables)
>> >
>> >Write the program without recursion and you know at compile-time how
>> >much memory it will ever need in the worst case.
>> >There is always at least one page - so make sure you use less than that.
>> >You'll need to know the stack overhead of any c-library you use - so
>> >don't use it or figure it out. It is doable with open-source libraries.
>>
>> TBH, I don't see the point. I know I have more than enough RAM to
>> handle most cases, and some extra swap for contingencies.
>>
>> If I do run out of VM, I just need to run fewer jobs at once, or add
>> another chunk of swap. No big deal.
>
>That shows that you are in a single user environment. Please consider the
>cases of larger systems where there may be 50 - 100 concurrent users, each
>with up to 100 processes on a cluster system. Now who is to be penalized
>for the short sighted design. It usually means the system will not be
>purchased because of the "buggy" OS that cannot manage the load.
"Cannot handle the load"? If you overload it, then problems occur.
Next time the DoD is purchasing transport aircraft, we'll try
drop-testing them all from 45 000 feet, then refuse to buy the ones
which "cannot handle the load"...
The system operates correctly within the specified limits. If you
overload it, it cannot fulfil all the demands put on it and fails
partially in some well-defined way.
>Your alternative are correct - but how do you determine which is to be done
>for the illustrated server? Without resource accounting, and enforcement
>you cannot. There is no data available to make the decision.
There is some data. It is not adequate to make a PERFECT decision;
some friendly casualties will occur. Until better resource accounting
is available, this can't be improved much. Either way, overcommitting
memory helps.
James.
-
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:31 EST