Messages in this thread |  | | Date | Tue, 22 Aug 2000 14:29:22 +0100 (BST) | From | Tigran Aivazian <> | Subject | Re: 2.4.0-test6 memory leak? |
| |
On Tue, 22 Aug 2000, Forever shall I be. wrote: > especially when I'm attempting to run programs and watching them > get killed because there's no more memory left..
ah... you didn't say that, did you? If you do get processes killed because of oom you may indeed have some sort of leak (but not necessarily).
Apply memleak from the IKD patch
ftp://ftp.kernel.org/pub/linux/kernel/people/andrea
and see if you catch any leaks.
But you can get the processes killed even without any leaks. Although the Linux VM doesn't overcommit any memory (see calls to vm_enough_memory() from brk, mmap etc.) it calculates the available amount but doesn't allocate anything until that memory is faulted in. I call it delayed allocation, many people call it "memory overcommit" and demand that VM keeps track of all such requests (and corresponding backing store) to guarantee that if any process decides to fault all their "allocated" areas they should be satisfied, like in SVR4. People sometimes attach the label "enterprise-level" to such behaviour, see page 147 Reserving Kernel Resource of McKusic's 4.4BSD book. He mentions the special flag to mmap to give Linux-like behaviour (i.e. process accepts responsibility to handle asynchronous faults in mapping), whilst I think it should be other way around, i.e. Linux behaviour default and the "enterprise-class" behaviour with a special flag to mmap.
Yes, apps can't usually handle memory failures asynchronously (on page fault) and it would be nice to only do it synchronously (return from sbrk, fork/mmap etc) but to sacrifice the wonderful Linux behaviour (as at present) is, imho, too much of a price to pay.
Regards, Tigran
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
|  |