[lkml]   [2000]   [Mar]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Overcommitable memory??
    On Thu, 16 Mar 2000, James Sutherland wrote:

    >On Wed, 15 Mar 2000, Paul Jakma wrote:
    >> On Mon, 13 Mar 2000, Michael Bacarella wrote:
    >> 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
    >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.

    Sorry, you're wrong. No physical memory (RAM or swap) is actually given to
    a process until after the program touches the page; malloc() alone is not
    sufficient. Proof is below.

    >> 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.

    No, it does not. The malloc() call returns a pointer to a region of
    address space that will be filled by the kernel if and when those pages
    are faulted. No physical pages (RAM or swap) are allocated by a call to
    malloc(), no mater how /proc/sys/vm/overcommit_memory is set.

    >> > 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.

    Sorry, you're wrong on this one. Even with /proc/sys/vm/overcommit_memory
    set to 0, you can easily have a task malloc() a region larger than the
    available virtual memory.


    [root@sleepy dwhysong]# echo "0" > /proc/sys/vm/overcommit_memory
    [dwhysong@sleepy dwhysong]$ cat mem.c
    int main(int argc, char *argv[]) {
    char *a;
    unsigned n;
    n = atoi(argv[1]);
    a = (char *) malloc(1024*1024*n);
    printf("Allocating %u megabytes at %p\n",n,a);
    [dwhysong@sleepy dwhysong]$ gcc mem.c -o mem
    [dwhysong@sleepy dwhysong]$ free
    total used free shared buffers cached
    Mem: 257788 98764 159024 19400 37708 32264
    -/+ buffers/cache: 28792 228996
    Swap: 642016 2200 639816
    [dwhysong@sleepy dwhysong]$ ./mem 800
    Allocating 800 megabytes at 0x40108008
    [dwhysong@sleepy dwhysong]$ ./mem 1000
    Allocating 1000 megabytes at (nil)

    So malloc() returns success when I ask for an 800 megabyte array on a
    machine with only ~640 megabytes of free virtual memory.


    David Whysong
    Astrophysics graduate student University of California, Santa Barbara
    My public PGP keys are on my web page -
    DSS PGP Key 0x903F5BD6 : FE78 91FE 4508 106F 7C88 1706 B792 6995 903F 5BD6
    D-H PGP key 0x5DAB0F91 : BC33 0F36 FCCD E72C 441F 663A 72ED 7FB7 5DAB 0F91

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:57    [W:0.065 / U:0.160 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site