WARNING: DON'T TRY THIS TRICK ON YOUR PRODUCTION SERVER OR YOUR LOVELY WORKSTATION, AS THIS COULD LEAD TO DATA CORRUPTION. IF YOU REALLY WANT TO KNOW WITHOUT TAKING RISK, DO IT ON UNUSED PC OR INSIDE VIRTUAL MACHINE (EG: VMWARE)! I DON'T TAKE ANY RESPONSIBILIY FOR ANY DAMAGE THAT MIGHT HAPPEN. YOU'VE BEEN WARNED!
In the middle of writing my next article for CHIP, I am courious of one thing...that is "What will happen if mount an tmpfs based directory which has size way bigger than RAM+Swap and copy a huugeee file there"?. Pushed by courisity, I decide to test it.
First, here is how to create the "tmpfs" directory:
# mount -t tmpfs -o size=3G tmpfs /mytmpfs
You don't need to precisely use "3G". Just use any number that actually bigger than your RAM+swap. If you got trouble on determining your RAM + swap size, simply use "top" and check the related entries.
Confirm it via "df -h" that our new directory is actually mounted and the size is correct. Now, you need a big file, preferrably has same size like your new tmpfs directory. Don't have one? "dd" comes to rescue :)
# dd if=/dev/zero of=./coba.saja bs=1k count=1572864
That will roughly create a 1.5Gigabyte filled with zeros :) For final touch, copy it to "mytmpfs"
# cp ./coba.saja /mytmpfs
Just sit and enjoy the show. To bring more thrill, fire up "top" and watch your RAM and swap are slowly occupied by our giant file. Then, sooner or later, your Linux system will "freeze". It's not actually frozen. What really happens here is a race between kswapd (which tries to clear up RAM so you can put the file there) and "cp" (which tries to put the file there).
Your tasks are practically forced to swap out and this creates "frozen" effect. Why? because, in order to run, your application needs to be paged in..and that means, forcing kswapd to swap in the related pages and possibly swapping out pages which belongs to non active task. So. it's like:
your apps --> go to-> RAM < -- go to < -- your giant file
eventually, RAM and your swap is almost full. I said almost, because Linux kernel always reserve some pages for certain needs and these pages is non allocatable for user space applications. At this time, OOM(Out of Memory) killer kicks in! Sorry, I can't give you the screenshot :) In my PC, it wildly killed my X Session :) Thanks God, I only fired up several xterm and OpenOffice. Funny thing is, mpg123 is still playing (in "rap" mode...you know what I mean? ;) )
"can I choose which task I should kill in thise situation". Quick answer "No you can". Linux OOM killer employs simple algorithm that will kill an application which does the latest memory allocation. As you can see here, this isn't always a correct decision. But memory hogging tends to chew every single pieces of your RAM until last moment, so OOM killer is practically usable here.
Want another slow memory eater? try this
# tail -f /dev/zero
Until next time...until then, try to Google about "VM overcommit" for preventive solution :)