a) you should absolutely use a dedicated medium for swap, if you try what I outline below, lest you destroy a good USB stick and your data with it; and
b) if something goes otherwise goes wrong, and your data vanishes as a result, you should not blame me.
Anyway...
Because of my netbook's lack of RAM, I was thinking about putting a swap partition on a USB stick. USB stick reads are (supposedly) fast, paging occurs in the background (which I think should mitigate the effects of the slow write speed), and my experience with zram indicates that high-speed swap is almost as good as more RAM.
But I don't have any old/spare sticks at the moment, and it seems like a shameful waste of a USB stick anyway... Which is why I decided to use a 2 GB MicroSD card. Procedure looked something like this:
- Partition card with one huge partition, and run mkswap on it
- Put in an fstab entry for the SD card. Unfortunately I can't make it user unmountable, as mount/unmount doesn't work for swap.
- Provide sudo access to swapon/swapoff for users in the plugdev group.
- Insert card and reboot. The new, hopefully-fast swap space is now enabled!
Obviously this is the lazy budget way to do things. Maybe tomorrow I'll see if I can cobble up a udev rule to mount swap partitions on USB devices automatically. Anyway, for now the ugly sudo hack is necessary so you can turn off the SD card swap before removing it, and not crash your machine! So I figure one might as well go the whole way with ugly hacks.
Results
With SalixOS 13.37 KDE, 32-bit...
- iostat shows reads and writes to the device... Currently more reads than writes, probably because Linux was swapping a little during the last update.
- When swapping starts, performance takes a bit of a dive as expected. Based on pure perception, it's not as much of a dive as when relying only on hard disk swap space, but that isn't saying much.
- Firefox performance when not under load seems a little better (i.e. less freezing when rendering pages). But again, that's not saying much.
All in all the results are less than impressive, even considering that I'm using KDE 4, which skews things a bit in the general direction of sluggishness. hdparm reveals a likely reason why:
Code: Select all
root@grayarea:~# hdparm -t /dev/sdb
/dev/sdb:
Timing buffered disk reads: 56 MB in 3.04 seconds = 18.40 MB/sec
root@grayarea:~# hdparm -t /dev/sda
/dev/sda:
Timing buffered disk reads: 188 MB in 3.02 seconds = 62.33 MB/sec
My thoughts on this are as follows, in approximate order of estimated likelihood:
- Maybe these are poor quality USB media. Pricier sticks and cards might results - which would be too bad, since the whole point of this experiment is to be a cheapskate.
- Maybe this netbook's high-speed USB support is shoddy. Some computers definitely get better IO speed with USB media than others.
- Maybe Linux's paging mechanism isn't optimized for use with flash media. It's possible that what I'm doing is actually not even close to Windows Readyboost in terms of what it does. IIRC Readyboost is more aggressive about caching stuff on the USB medium, maybe it also incorporates some pager optimizations for such media to avoid unnecessary overhead and IO.
- Maybe my (mostly default) setup is not optimized for swapping to and from a flash medium. For instance, increasing vm.page-cluster might improve the performance of a flash device as swap space, by reducing the number of writes (which I'm guessing would be a bottleneck). This doesn't touch on the read speed issue though.
- Maybe the whole concept of Readyboost is actually stupid, and most removable flash media just do not perform adequately for it to have any benefit. Were this the case, though, I would not expect Microsoft to spend any effort adding Readyboost to Windows Vista and 7. Whatever else you can say about MS, they're not entirely stupid.
I'd be interested if anyone else has input on this, or is willing to try it out on a low-spec computer...