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.
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.
-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pollard@navo.hpc.mil
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:30 EST