Messages in this thread |  | | Date | Tue, 22 Aug 2000 14:34:34 +0100 (BST) | From | Tigran Aivazian <> | Subject | Re: 2.4.0-test6 memory leak? |
| |
On Tue, 22 Aug 2000, Tigran Aivazian wrote: > 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() ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
I know the above is an open flamebait, so let me state clearly that I am well aware of the fact that one can allocate the same 100M multiple times and I still don't call this "overcommit" because those 100M are available at the time of allocation, i.e. at the time vm_enough_memory() is called. Yes, if all processes want their memory immediately, some of them are going it get killed and that is an unfortunate fact of life, but I can live with it.
Regards, Tigran
> 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/ >
- 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/
|  |