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, James Sutherland wrote:

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

This is not strictly true; see below.

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

It depends on if you set /proc/sys/vm/overcommit_memory. The default state
has malloc() return 0 if your program asks for more than the TOTAL amount
of virtual memory (RAM+swap) on the machine. If you do "echo 1 >
/proc/sys/vm/overcommit_memory" then you can successfully malloc()
arbitrarily large memory regions.

[dwhysong@eleanor dwhysong]$ cat test.c
int main() {
char *a;
a = (char *) malloc(1024*1024*800);
printf("%p\n",a);
}
[dwhysong@eleanor dwhysong]$ gcc test.c -o test
[dwhysong@eleanor dwhysong]$ free
total used free shared buffers cached
Mem: 258352 125396 132956 50008 23152 26020
-/+ buffers/cache: 76224 182128
Swap: 386460 3500 382960
[dwhysong@eleanor dwhysong]$ ./test
(nil)
[dwhysong@eleanor dwhysong]$ su
Password:
eleanor:/mnt/data/home/dwhysong# cat /proc/sys/vm/overcommit_memory
0
eleanor:/mnt/data/home/dwhysong# echo "1" > /proc/sys/vm/overcommit_memory
eleanor:/mnt/data/home/dwhysong# ./test
0x400b5008
But the program runs and exits almost instantly, because it hasn't touched
the malloc()'ed memory:

[dwhysong@eleanor dwhysong]$ free
total used free shared buffers cached
Mem: 258352 125400 132952 50008 23152 26020
-/+ buffers/cache: 76228 182124
Swap: 386460 3500 382960

Nothing was swapped out... why? Because the program never actually touches
any of the 800 megabytes it allocates, so no page faults are generated for
this memory and the kernel never actually has to come up with the free
data pages for the process.

However, this works as expected:

[dwhysong@eleanor dwhysong]$ cat freemem.c
int main() {
char *a;
unsigned i;
a = (char *) malloc(1024*1024*250);
for (i=0; i<1024*1024*250; i+=4096) a[i]=0;
}
[dwhysong@eleanor dwhysong]$ gcc freemem.c -o freemem
[dwhysong@eleanor dwhysong]$ free
total used free shared buffers cached
Mem: 258352 200292 58060 17780 101116 16308
-/+ buffers/cache: 82868 175484
Swap: 386460 3596 382864
[dwhysong@eleanor dwhysong]$ ./freemem
[dwhysong@eleanor dwhysong]$ free
total used free shared buffers cached
Mem: 258352 72416 185936 3476 5260 7232
-/+ buffers/cache: 59924 198428
Swap: 386460 18868 367592

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    [from the cache]
©2003-2014 Jasper Spaans. Advertise on this site