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/
This archive was generated by hypermail 2b29 : Wed Aug 23 2000 - 21:00:06 EST