Swap performance - Swap Partition or Swap File?

---

Hi All,
I have been trying to find the best way to configure my swap for my android phone, currently the G1. I had started out with the regular swap partition but find my phone performance degraded over time thus I decided to test the usual read/write for my Class 6 Micro SDHC card.

Configure the SD card via fdisk and setup 3 partitions (like everyone else).

Command (m for help): p

Disk /dev/sdm: 8166 MB, 8166309888 bytes
224 heads, 56 sectors/track, 1271 cylinders
Units = cylinders of 12544 * 512 = 6422528 bytes
Disk identifier: 0x3114df25

Device Boot Start End Blocks Id System
/dev/sdm1 1 800 5017572 c W95 FAT32 (LBA)
/dev/sdm2 801 1100 1881600 83 Linux
/dev/sdm3 1101 1271 1072512 82 Linux swap / Solaris

Command (m for help): w
The partition table has been altered!

Calling ioctl() to re-read partition table.

WARNING: If you have created or modified any DOS 6.x
partitions, please see the fdisk manual page for additional
information.
Syncing disks.


Afterward, format the drive as vfat, ext3, swap

localhost ~ # mkfs.vfat /dev/sdm1
mkfs.vfat 3.0.1 (23 Nov 2008)
localhost ~ # mkfs.ext3 /dev/sdm2
mke2fs 1.41.3 (12-Oct-2008)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
117600 inodes, 470400 blocks
23520 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=482344960
15 block groups
32768 blocks per group, 32768 fragments per group
7840 inodes per group
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912

Writing inode tables: done
Creating journal (8192 blocks): done
Writing superblocks and filesystem accounting information: done

This filesystem will be automatically checked every 26 mounts or
180 days, whichever comes first. Use tune2fs -c or -i to override.
localhost ~ # mkswap /dev/sdm3
Setting up swapspace version 1, size = 1072508 KiB
no label, UUID=2046ef6b-ac5a-47a2-9484-ea2a356cc7fa

now the read performance via "hdparm -t /dev/sdxxx"

sdm1 (fat) = Timing buffered disk reads: 26 MB in 3.12 seconds = 8.34 MB/sec


sdm2 (ext3) = Timing buffered disk reads: 26 MB in 3.11 seconds = 8.35 MB/sec


sdm3 (swap) = Timing buffered disk reads: 26 MB in 3.08 seconds = 8.45 MB/sec


as you can see, reading is more or less the same across the board.

now the fun part of write. for fat and ext3, I decided to write to a file, for the swap partition, I decided to write directly to the partition.


FAT:

localhost ~ # dd count=30 bs=1M if=/dev/urandom of=sdm1/test.write
30+0 records in
30+0 records out
31457280 bytes (31 MB) copied, 4.9464 s, 6.4 MB/s


EXT3:

localhost ~ # dd count=30 bs=1M if=/dev/urandom of=sdm2/test.write
30+0 records in
30+0 records out
31457280 bytes (31 MB) copied, 4.94644 s, 6.4 MB/s

SWAP:

localhost ~ # dd count=30 bs=1M if=/dev/urandom of=/dev/sdm3
30+0 records in
30+0 records out
31457280 bytes (31 MB) copied, 8.79714 s, 3.6 MB/s


As you can see, write to a FAT or EXT3 partition seems to be faster than writing to a swap partition. Of course, this is assuming I have done my test correctly . If writing to FAT or EXT3 is faster and reads are the same, would it mean that you get better SWAP performance via a swap file on an EXT3 partition?

thanx for the interesting read

Your write test is flawed.

Flaw 1: You use /dev/urandom as a data source. Data generation from /dev/urandom is heavily affected by CPU usage AND by available entropy -- though it doesn't block, its speed does vary drastically.

Flaw 2: You only run the test ONCE. This means that issues from flaw 1 are totally visible rather than being averaged out over a large number of tests. You should do the test 100's of times and take the average over them.

Flaw 3: Implementation of the ext3 filesystem tend to hide the effects of disk latency. There are caches and journals that you haven't accounted for. In order to get the ACTUAL time that it takes to write to the ext3 filesystem, you need to follow the write test by a synchronization, which will *actually* write the data to the disk (i.e., it will BLOCK until the write is actually completed). Unfortunately though, this test will also synchronize OTHER write operations that are buffered, which will further skew your results. What you REALLY need to do is perform the tests on a completely empty partition. Should be starting sync, begin time, test write, finishing sync, finishing time. Elapsed time = finishing time - begin time.

In other words, I'm sorry, but your conclusions are not correct. What I *very strongly* suspect, is that if you do your tests correctly, you will find that the performance of swap-on-ext3 will actually be *lower* than swap-on-partition due to the extra overhead of the ext3 filesystem.

Note: the linux vfat filesystem implementation also buffers writes.

A little bit of fun trivia:
Back in the days when we actually used floppy disks, you could actually copy an entire disk worth of data over to a vfat floppy disk without it even BEGINNING to write to the disk. Usually, it would begin writing several seconds after the copy "completed". If you wanted to speed it along, a sync or umount would force the buffer immediately to write to disk.

ahhh...thanks for the info. I guess with buffer, it makes timing or calculating the write speed a bit difficult. I will have to think more about this.


This really makes me wonder how do SD card manufactures test their write speed and assign the card class.

I believe they do a test similar to yours without any buffering and write different amounts of data to simple file systems.

Then, according to http://en.wikipedia.org/wiki/Secure_Digital the class number is equal to the amount of minimum write megabytes per second that can be written to the disk when in a clean and unfragmented state. So a class 6 card would at it's slowest writing speed on a perfectly setup disk be able to write data at 6 megabytes per second or faster. Read speed isn't taken into account for the rating, but is generally faster than write speed.

I redid my test with raw write via if=/dev/zero and the write speed is now on-par with what was classified on the SD class. (7.4MBps write on my class 6). Playing around w/ the setting more, seems like the over-time degradation seems to be caused by my swappiness configuration.