Messages in this thread | | | Date | Wed, 15 Mar 2000 16:23:49 +0000 (GMT Standard Time) | From | Paul Jakma <> | Subject | Re: Overcommitable memory?? |
| |
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.
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.
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.
> -MB >
-paul jakma.
- 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/
| |