lkml.org 
[lkml]   [2000]   [Mar]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: Overcommitable memory??
    On Wed, Mar 15, 2000 at 10:36:21PM +0000, James Sutherland wrote:
    > On 15 Mar 2000, Rask Ingemann Lambertsen wrote:
    >
    > > Den 13-Mar-00 22:26:50 skrev James Sutherland følgende om "Re: Overcommitable memory??":
    > > > On Mon, 13 Mar 2000, Michael Bacarella wrote:
    > > >> There's no reason to tell an application that it has X megs of memory all
    > > >> to itself to play with, and then KILL one of it's brothers if the kernel
    > > >> finds itself short.
    > >
    > > > We don't "tell" any application we have X Mb of RAM.
    > >
    > > Actually, we do. If malloc (262144) returns non-zero, then we've told
    > > the application that we have 256 kB of memory, implemented as RAM or swap
    > > in any combination the kernel sees fit, as long as there is 256 kB in total.
    >
    > No, we have GIVEN it 256K of RAM. We don't say "We've got 255Mb of RAM,
    > how much would you like?", the app says "I need 17384Kb of RAM to operate.
    > Can I have it please?". Either the kernel says "yes", and it works, or it
    > says "no", and the app gives up.
    >
    > The problems occur when it decides it would like another chunk of RAM, and
    > is told it can't have it - at which point (since it only asked because it
    > NEEDED the RAM) it will almost always have to give up.
    >
    > We NEVER allocate memory via malloc() and then later discover we can't
    > honour that allocation - once the memory has been allocated, it is the
    > property of that process, to do with as it pleases.

    malloc(3) is a libc function. It may reuse free(3)d memory if there
    is a chunk of sufficient size, otherwise it uses brk(2) to expand the
    heap. The new pages aren't actually allocated until written to
    (unless mlockall() was called).

    Once written to, the new area gets faulted in through the COW
    handler. So it is possible that malloc succceeds without the memory
    being available later on (when overcommit is disabled the brk(2) will
    only succeed when the _current_ situation allows the new area to be
    faulted in completely).

    --
    Andreas E. Bombe <andreas.bombe@munich.netsurf.de>
    http://home.pages.de/~andreas.bombe/ DSA key 0x04880A44

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.rutgers.edu
    Please read the FAQ at http://www.tux.org/lkml/

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