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

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.

Example:

[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);
return(0);
}
[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.

Dave

David Whysong dwhysong@physics.ucsb.edu
Astrophysics graduate student University of California, Santa Barbara
My public PGP keys are on my web page - http://www.physics.ucsb.edu/~dwhysong
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 majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

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