I started playing with using the extra video ram on the dc for swap
after someone pointing me this article:
http://hedera.linuxnews.pl/_news/2002/09/03/_long/1445.html
As I'm sure many of you know, there's 8192k of video memory on the dc,
and if you're only using an unaccellerated 640x480x16 framebuffer,
you're only using 600k of that. To prove that it's worthwhile, I've
run some performance numbers. All of these are simply timing a kernel
build, doing a make clean, and swapoff/swapon in between. If I were
on a system w/ more memory maybe I would have worried about buffer
cache but I don't think it's important here. I'm running the 7/28
base + updates from debian.dodes.org using nfsroot. I'm also using
a 2.4.18 kernel + linux-sh + linux-sh-dc + nfs-swap. Here's the
data:
NFS swap, make clean, make zImage
real 80m35.143s
user 63m6.430s
sys 4m48.220s
VRAM swap + NFS swap, make clean, make zImage
real 72m0.480s
user 62m54.910s
sys 3m57.560s
~10% improvement, not bad. Now if your system really gets hammered:
NFS swap, make clean, MAKE="make -j2" make zImage
real 367m50.110s
user 67m32.910s
sys 231m31.150s
VRAM swap + NFS swap, make clean, MAKE="make -j2" make zImage
real 292m53.256s
user 66m57.060s
sys 174m9.540s
~20% improvement! This is likely the worst I've pounded the dc.
In most cases, just building debian packages, the most I've seen
are 2 compiles running at once. The parallel build can do parallel
across directories, so more the 2 things can be going at once.
Here's some snippets of my config if you want to reproduce:
/etc/modules
mtdblock
slram
blkdev_swap
/etc/modutils/slram
options slram map=VRAM,0xa5096000,+0x76a000
post-install slram /sbin/mkswap /dev/mtdblock0
/etc/fstab
/dev/mtdblock0 none swap sw,pri=1 0 0
/swap/swap none swap sw,pri=0 0 0
(/swap/swap is my nfs swap)
I'm not on the list, so please CC for followup. Have fun,
Alex
|
