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, 15 Mar 2000, Paul Jakma wrote:

    > On Mon, 13 Mar 2000, Michael Bacarella wrote:
    >
    >
    > > The way I see it, apps that have successfully allocated memory in the past
    > > wouldn't start dying since there's no malloc() to fail, wheras new apps
    > > that want to bring down the system will start getting failed
    > > malloc()/mmap()'s
    >
    > no. Because a good app may have malloc()'ed memory an hour ago, and only
    > now try to write to it. Now the kernel had overcomitted on that
    > malloc(), and an hour ago things looked ok. But now when the kernel
    > tries to fulfill it's promise it finds it has no memory.

    That doesn't happen. malloc() ALLOCATES the memory to the process. It is
    *NOT* overcommitted. It may be backed by swapspace rather than physical
    memory, but that block of memory *IS* available to the process.

    > what does it do? the process didn't make a system call, so we can't
    > return to it. You can only really signal it (probably killing it),
    > suspend it (but that doesn't help reclaim memory) or kill something.
    >
    > catch-22.
    >
    > >
    > > 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.
    > >
    >
    > it's a choice. You can either
    >
    > a) allocate swap/pages at the time of malloc()/fork() et al.
    > This incurs costs. Both in memory/swap usage, and in time - you need to
    > allocate backing store on the hard disk, you need to setup pages in
    > memory - all for memory that might never be used.

    malloc() does this. fork() doesn't, because there is no memory to
    allocate. The whole point of fork() is that you are *NOT* simply
    duplicating the in-VM image of the process! VERY early Linux kernels did
    this - and had problems spawning multiple shells, never mind actually
    running processes, as a result.

    > b) you overcommit, and try to minimise the risks.
    >
    > > But on the other hand, malloc() DOES return EAGAIN. Some applications
    > > would think to retry malloc() in a few seconds, which may have hopes of
    > > succeeding.
    > >
    >
    > but that only applies to processes that try malloc() at the point of
    > OOM. You still have a bunch of processes with memory they have already
    > malloc()'ed but havn't allocated yet.

    Nope.



    James.


    -
    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:4.175 / U:0.168 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site