On Mon, 6 Mar 2000, Paul Jakma wrote:
> On Fri, 3 Mar 2000, Alan Cox wrote:
>
> > > Isn't this what /proc/sys/vm/overcommit_memory is for??
> >
> > Thats a quick heuristic check on/off not a detailed bit of accounting
>
> another question, forgive me if it's stupid: Why do we even allow
> overcommited memory? What reason is there is to support app's that
> malloc() a huge amount of memory without using that memory?
Think about running a big simulation process that fork()s to
exec() /bin/mail in order to email its status or a partial
solution to the person that started the simulation.
A big rendering process that fork()/exec()s lpr.
Without overcommit you'd need to have the 500 MB of swap free
that the big simulation is using, even though it'll only use
1 MB for the little process that's being exec()ed...
> (i'm having a discussion with some other unix users at the
> moment about linux's OOM vulnerability).
It's not a vulnerability as such, it's more of a design
decision. Overcommit makes sense in a *lot* of situations.
Running more programs than what can fit in your memory
never makes sense, the difference between overcommitting
and non-overcommitting systems is how they handle an
overload situations.
Non-overcommitting systems will refuse further allocations
when memory _could_ be filled up by all current processes.
Overcommitting systems will allow the system to go much
further, possibly processing the same load that a non-overcomm.
system would not be able to process. However, when it breaks
down it breaks down in a slightly less predictable way ...
regards,
Rik
-- The Internet is not a network of computers. It is a network of people. That is its real strength.http://www.conectiva.com/ http://www.surriel.com/
- 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 : Tue Mar 07 2000 - 21:00:20 EST