On Thu, 16 Mar 2000, Richard B. Johnson wrote:
> On Thu, 16 Mar 2000, James Sutherland wrote:
> > On Wed, 15 Mar 2000, Paul Jakma wrote:
> > > On Mon, 13 Mar 2000, Michael Bacarella wrote:
> > > > The way I see it, apps that have successfully allocated memory in the past
> > > > wouldn't start dying since there's no malloc() to fail, wheras new apps
> > > > that want to bring down the system will start getting failed
> > > > malloc()/mmap()'s
> > >
> > > no. Because a good app may have malloc()'ed memory an hour ago, and only
> > > now try to write to it. Now the kernel had overcomitted on that
> > > malloc(), and an hour ago things looked ok. But now when the kernel
> > > tries to fulfill it's promise it finds it has no memory.
> >
> > That doesn't happen. malloc() ALLOCATES the memory to the process. It is
> > *NOT* overcommitted. It may be backed by swapspace rather than physical
> > memory, but that block of memory *IS* available to the process.
> >
>
(snip description of standard VM mechanism)
Yes, I know how VM works - I thought, though, that Linux allocated memory
when instructed to via malloc().
> The problem with many Unix's, including Linux, is that the page-stealing
> is done by stealing pages from sleeping tasks. The idea is that many are
> daemons that may never wake up. Sooner or later, somebody will implement
> a page-stealing algorithm that steals pages from the task that keeps
> demanding more and more virtual memory. This will allow a memory hog
> to continue without disrupting the entire system.
Unless that memory hog takes ALL the memory, which is the circumstance
this thread was discussing. At this point, there isn't any memory left for
anyone, so processes start dying. We need to make sure it is the memory
hog which dies, not the other processes.
> The memory-hog will get slower and slower because its pages keep getting
> faulted in and out of disk storage. This will allow well designed programs
> to run well and poorly designed programs to run poorly.
Until you reach an OOM state, at which point most things runs rather dead.
EXCEPT the memory hog, with the old behaviour - almost everything else
dies. We need something to kill the memory hog before it kills everything
else - enter Rik's patch.
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:19 EST