lkml.org 
[lkml]   [2000]   [Aug]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 12:37    [W:0.038 / U:3.344 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site