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.
> what does it do? the process didn't make a system call, so we can't
> return to it. You can only really signal it (probably killing it),
> suspend it (but that doesn't help reclaim memory) or kill something.
>
> catch-22.
>
> >
> > There's no reason to tell an application that it has X megs of memory all
> > to itself to play with, and then KILL one of it's brothers if the kernel
> > finds itself short.
> >
>
> it's a choice. You can either
>
> a) allocate swap/pages at the time of malloc()/fork() et al.
> This incurs costs. Both in memory/swap usage, and in time - you need to
> allocate backing store on the hard disk, you need to setup pages in
> memory - all for memory that might never be used.
malloc() does this. fork() doesn't, because there is no memory to
allocate. The whole point of fork() is that you are *NOT* simply
duplicating the in-VM image of the process! VERY early Linux kernels did
this - and had problems spawning multiple shells, never mind actually
running processes, as a result.
> b) you overcommit, and try to minimise the risks.
>
> > But on the other hand, malloc() DOES return EAGAIN. Some applications
> > would think to retry malloc() in a few seconds, which may have hopes of
> > succeeding.
> >
>
> but that only applies to processes that try malloc() at the point of
> OOM. You still have a bunch of processes with memory they have already
> malloc()'ed but havn't allocated yet.
Nope.
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