Re: 2.4.0-test6 memory leak?

From: Tigran Aivazian (tigran@veritas.com)
Date: Tue Aug 22 2000 - 08:34:34 EST


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/



This archive was generated by hypermail 2b29 : Wed Aug 23 2000 - 21:00:06 EST