gzip and swap test

gistfile1.txt

# match media01
sudo sysctl vm.swappiness=0
sudo echo 2 > /proc/sys/vm/overcommit_memory
sudo echo 50 > /proc/sys/vm/overcommit_ratio

vim /memtest.sh
#!/bin/bash
D=/tmp/$1
mkdir $D
mount -ttmpfs $D $D # by default is sized to half of physical memory
dd if=/dev/zero of=$D/test bs=1M # will fill that partition
:wq
/memtest.sh a # fill first half of physical memory
/memtest.sh b # fill second half of physical memory
/memtest.sh c # overcommit beyond physical memory
/memtest.sh d # overcommit beyond physical memory even more
# continue on...
# normally machine freezes once swap is full
# but notice that swap still fills according to vm.swappiness

root@all-in-one01:/tmp# cat /dev/zero | gzip > test                                                       │

# notice that at no point (with any settings) does gzip cause swap usage

i think this test demonstrates that the overcommit setting only allows processes to request more memory than the machine actually has, but doesn't impact a) whether swap is used, or b) when/how much is used
[12:19:17 PM] Mike Smullin: and i think it also demonstrates that gzip, by itself, doesn't even use swap.

i am wondering if swap is something the kernel controls system-wide, and not requestable by individual processes. it seems that way

i was able to use
swapoff -a
and the tmpfs never went into swap.

see also: http://serverfault.com/questions/372020/what-are-the-best-possible-ways-to-benchmark-ram-no-ecc-under-linux-arm