Messages in this thread | | | Date | Thu, 16 Mar 2000 10:34:00 +0000 (GMT) | From | James Sutherland <> | Subject | Re: Overcommitable memory?? |
| |
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/
| |