Messages in this thread | | | Date | Thu, 16 Mar 2000 11:16:46 -0800 (PST) | From | David Whysong <> | Subject | Re: 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/
| |