Skip to contentSkip to conversation

VM and swap - it's really unusable

2.4.17/18pre [email protected] 2 participants 3 messages Jan 6, 2002 – Jan 8, 2002

lore
Share & tools
lore
#0 lore raw

2.4.17rc2aa2 seems to handle the grow/shrink of buffer_head, dentry_cache, inode_cache slabs and page/buffer caches pretty well.

Machine has 1GB RAM and CONFIG_NOHIGHMEM=y
1027 MB swap.

root# dmesg|grep Mem
Memory: 901804k/917504k available (1049k kernel code, 15312k reserved, 259k data, 236k init, 0k highmem)

root# uptime
2:47pm up 4 days, 17:04, 12 users, load average: 1.00, 1.00, 1.00

# Run updatedb to expand the size of dentry_cache. root# updatedb

# At first, slabs are fairly large.
root# egrep 'inode_cache|dentry_cache|buffer_head' /proc/slabinfo

inode_cache       469072 469168    512 67024 67024    1
dentry_cache      539651 539670    128 17989 17989    1
buffer_head       119438 126330    128 4211 4211    1

Machine has been up for a while, compiling things, running tests, etc, so page and buffer caches are large too. That's expected/desireable as there is no memory shortage.

root# free -mt
total used free shared buffers cached
Mem: 880 868 11 0 152 316
-/+ buffers/cache: 400 480

Swap:         1027          0       1027
Total:        1908        868       1039
# count processes
root# ps axu|wc -l
     64
# allocate and write to 99% of virtual memory
root# time ./mtest01 -p 99 -w
Filling up 99%  of ram which is 1855075778d bytes
PASS ... 1855979520 bytes allocated.
real    0m39.006s
user    0m8.610s
sys     0m7.170s
# notice how much the slabs shrank compared to above.
root# egrep 'inode_cache|dentry_cache|buffer_head' /proc/slabinfo
inode_cache          254    658    512   94   94    1
dentry_cache         193   1140    128   38   38    1
buffer_head         8609  43650    128 1455 1455    1

# Memory allocated to buffers/cache has decreased considerably too. root# free -mt
total used free shared buffers cached

Mem:           880         71        809          0         29          6
-/+ buffers/cache:         35        845
Swap:         1027         27       1000
Total:        1908         98       1810
# no processes killed by OOM
root# ps aux|wc -l
     64

# Now force an OOM condition
root# time ./mtest01 -p 101 -w
Filling up 101% of ram which is 1916602941d bytes Killed

real    0m40.083s
user    0m8.770s
sys     0m7.270s

Note the time to notice and kill mtest01 because of OOM is short. 39 seconds to allocate 1855979520 bytes of VM.
40 seconds to allocate 1916602941 bytes and kill with OOM handler.

# Only mtest01 killed by OOM
root# ps axu|wc -l

     64

In the experiment above, it appears the rc2aa2 VM shinks slabs and page/buffer caches in a reasonable way when a process needs a lot of memory.

Signature · 1 line
Randy Hron
#1 lore raw
Quoted 3 lines · On Sun, 6 Jan 2002 15:38:54 -0500 [email protected] wrote:

In the experiment above, it appears the rc2aa2 VM shinks slabs and page/buffer caches in a reasonable way when a process needs a lot of memory.

Hello Randy,

can you please try The Same Thing while copying large files around in the background (lets say 100MB files) and re-comment.

Thanks,
Stephan

#2 lore raw
In reply to [email protected]
Quoted 5 lines

can you please try The Same Thing while copying large files around in the background (lets say 100MB files) and re-comment.

Thanks,
Stephan

I used the script below to create 10 330 megabyte files; then cpio them over to another filesystem while another process was constantly allocating and writing to 85% of VM. It did 77 iterations allocating about 1.6GB of RAM during the time (10 * 330 * 2) MB worth of files were created and cpio'd. The test took 53 minutes.

I do most of my work from console.
http://home.earthlink.net/~rwhron/hardware/matrox.html

There was an obvious but not painful delay for interactive use during the test. An X desktop would be less kind to the user.

Kernel: 2.4.17rc2aa2
Memory: 901804k/917504k available
1027 MB swap.
Athlon 1333
(1) 40GB 7200 rpm IDE disk.

#!/bin/bash
# What does the VM do when copying big files and a memory hog is running.

cmd=${0##*/}
kern=$(uname -r)

typeset -i i
typeset -i j

log=${cmd}-${kern}.log
src=/usr/src/sources
dest=/opt/testing
mtest01=$src/l/ltp*206/testcases/bin/mtest01
percent=85 # vm to fill

uname -a > $log

# create memhog script to run during test
cat>memhog<<EOF
#!/bin/bash
while :
do	# allocate and write to $percent of virtual memory
	uptime
	head -3 /proc/meminfo
	egrep 'inode|dentry|buffer' /proc/slabinfo
	time $mtest01 -p $percent -w 2>&1
	head -3 /proc/meminfo
	egrep 'inode|dentry|buffer' /proc/slabinfo
done
EOF
# execute memhog in background
chmod +x memhog
/memhog >> $log 2>&1 &
mpid=$!
# timer
SECONDS=0
vmstat 15  >> $log &
updatedb
rm -rf $src/?/bigfile $dest
mkdir $dest
df -k /opt /usr/src >> $log
# create 10 big files
for ((i=0; i<=9; i++))
do	cat $src/[gbl]/*.{gz,bz2} > $src/$i/bigfile
done
ls -l $src/?/bigfile >> $log
size=$(ls -l $src/?/bigfile|awk '{print $5}'|uniq)
num=$(ls $src/?/bigfile|wc -w)
# copy the files
cd $src
find [0-9] -name bigfile|cpio -pdm $dest >> $log
sync
df -k /opt /usr/src
echo $SECONDS to create and copy $num $size byte files  >> $log
# kill memhog and vmstat
kill $! $mpid
rm -rf $src/?/bigfile $dest
echo "log is in $log"
Signature · 1 line
Randy Hron