James Sutherland <jas88@cam.ac.uk>:
> On Sun, 19 Mar 2000 19:59:33 -0800 (PST), you wrote:
>
> >On 19 Mar 2000, Rask Ingemann Lambertsen wrote:
> >>Den 16-Mar-00 20:18:09 David Whysong wrote:
> >>> On 15 Mar 2000, Rask Ingemann Lambertsen wrote:
> >>>>Den 14-Mar-00 18:32:49 Rik van Riel wrote:
> >
> >>>>> Not really. Without overcommit you may still have random program
> >>>>> crashes and lost work...
> >>>>
> >>>> Yes, really. Maybe I should have said "additional lost work" instead
> >>>>of just "lost work". Without overcommit, program crashes will only
> >>>>happen due software bugs or hardware problems.
> >> ^^^^^^^^^^^^^^^^^
> >>
> >>> Not true. With no overcommit, you can still crash programs due to OOM
> >>> situations.
> >>
> >> Sure, not all programs are bug free. But that's a whole lot different
> >>from having the kernel kill processes just because the kernel fails to
> >>perform basic bookkeeping.
>
> It is NOT "failing to perform basic bookkeeping". It is simply
> deferring memory allocation until the memory is used.
Ummm - yes it is. If the "deferring memory allocation" means that someone else
can use the resources instead then the bookkeeping is not tracking the
allocated (but not yet used) memory. It HAS been allocated to the first
process. If it also allocated to another process then you a double dipping
and eventually that will kill one, two, or all processes.
> >I said crash due to OOM, not due to bugs. I never said anything about bugs.
> >
> >You can't avoid memory overcommit without dealing with:
> > 1. mmap()'ed data
> > 2. stack growth
> > 3. kernel dynamic memory allocation
> >
> >...and probably a host of other things I know nothing about. You're
> >talking about adding a tremendous amount of overhead and complexity for no
> >real benefit.
>
> Yes. Disabling demand-allocation would cost you a LOT of
> functionality.
Not talking about the modification of process page tables to add a data page
to them. We are talking about not modifing the process page tables when that
modification causes the users total number of pages (used) exceeds the users
quota limit.
>
> >>> Memory overcommit is here to stay. As I recall, Linux already used
> >>> overcommit and COW when I started using it at version 0.99pl13.
> >>
> >> So what is /proc/sys/vm/overcommit_memory for, if not to make
> >>overcommitment of memory an _option_?
> >
> >It has already been shown on this list that
> >
> ># echo 0 > /proc/sys/vm/overcommit_memory
> >
> >does not, in fact, disable memory overcommit.
>
> You CAN, however, disable overcommit (i.e. deferred allocation of VM)
> on a per-process basis, simply by touching memory when you allocate
> it. Hey presto! You have non-overcommitted VM for your process.
That still doesn't disable it. The OOM condition still occurs.
> >>> Get used to it, or find another OS...
> >>
> >> You're such a good Linux advocate...
> >
> >Hey, this is core stuff that has been in the kernel for a very long time.
> >It's not going to change, and it shouldn't be changed.
>
> Agreed.
It should change when something better is available. The techniques are
available. They should be used.
Overcommit is usefull on single user workstations where it has been
determined that its use is proper.
Overcommit is VERY BAD when used where significant damage ensues when a
failure occurs. Multi-user servers and embeded systems are two such areas
where overcommit causes serious problems.
Now for a slightly odd set of possiblities:
1. Which is more reliable a) Linux b) NT ?
2. Which would you want firing missiles at you?
3. What happens if the ship goes OOM ocassionaly?
Guess the OS used for the ship?
-------------------------------------------------------------------------
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