Swap space increases the virtual memory capacity of your machine. If you have a 16 MB machine. 2MB is used by the kernel and trashed buffers, leaving you 14.

This 14 MB is a window on all the code that can be reloaded from binaries on the disk, and other pages stored on the swap device files. You want to have about 64 MB swap, though you probably won't use more than 32 MB.

More virtual memory allows you to run more programs at once, and bigger programs, that you would otherise have to avoid.

To make your machine faster, add another 16 MB of real memory, but why does a lack of swap space make your machine slower ?

Basically, unused data pages get paged out to the swap disk(s). But if you don't have any more swap space, they can't. So instead program pages get dropped and reloaded from their files. The worst case is where you have 4K left, and every CPU jump requires a new page to be loaded.

A swap partition is a disk partition with the fdisk-82 tag, and the markers left by mkswap.

It is usually a linear array of 1K device blocks, grouped as 4k mmap pages. You create one on the least popular disk.

fdisk /dev/hdc	  # create a 30 MB partition on a drive
		  # set it's partition tag to 82
mkswap /dev/hdc12 # change this or die
vi /etc/fstab	  # add the following line

/dev/hdc12       swap         swap        defaults       0

free		# see how much memory is in use
swapon -a	# add all swap partitions listed in /etc/fstab
free		# check it worked

Swap partitions are easier to find than swap files at boot time (the system looks in /etc/fstab), and easier for sysops's to find. fdisk -l gives a list. However files are eaier to create and delete, without having to rebuild your disk(s), and you can switch them to select which disks are used.

Swap partitions are ususally faster than swap files, because the system has to locate all the blocks of the swap space through the file's inode and indirect block map.

Swap files may be faster than partitions, when the swap space AND the programs have to be on the same disk, because the swap file sectors are closer to the program sectors (being in the same partition). Seperate partitions guarantees that the disk head will have to move away from this partition. However, seperate physical disks is the best, as neither a swap seek or a program seek effects the other disk, possibly leaving the disk head close to the NEXT request!

To me it is more convenient to set up several clearly labelled swap partitions on every disk. If you don't need them all, Edit /etc/fstab and comment out the one on the most used disk.

If you choose to use swap files, you want to do so on an unfragmented disk, so that blocks in the swap file are sensibly packed. Any swap code optimisation will presume that it is a contiguous 4k page device, and may bring certain pages together. One day eh?

mount /hda1
mkdir /hda1/swap_files

dd if=/dev/zero of=/hda1/swap_files/swap_16_a bs=1024k count=16
mkswap /hda1/swap_files/swap_16_a 16384

dd if=/dev/zero of=/hda1/swap_files/swap_64_e bs=1024k count=64
mkswap /hda1/swap_files/swap_64_e 65536

# every boot: /etc/rc.d/rd.swap_files

swapon /hda1/swap_files/swap_16_a 
swapon /hda1/swap_files/swap_16_b 
swapon /hda1/swap_files/swap_16_c 
swapon /hda1/swap_files/swap_16_d 
swapon /hda1/swap_files/swap_64_e 
	-or-
swapon /dos/c/lgx/swaps/swap16.a
swapon /dos/c/lgx/swaps/swap16.b
swapon /dos/c/lgx/swaps/swap16.c
swapon /dos/c/lgx/swaps/swap16.d
swapon ...

Before and after you create a swapfile (if you have the time) run the command described in the "disk space" section, which is more or less:

echo show_super_stats 		\
| debugfs  /dev/hda1 		\
| less

That's broken your train of thought for swap, but the idea is when creating swap files, that's how you watch out for where they are created on the disk. Not much difference from partitions, but closer, possibly between your data and program head seeks. A partition would be guaranteed to be al least outside of this partition!

Inside the intel 386, is a builtin MMU with mappable 4K pages. The 486 and Pentium chips are just 386 chips with go-faster-stripes, and occasional new op-codes. (You can agrue that the 'go-faster-stripes' are actually significant internal structural changes, but the result is much the same).

In 386 mode, every process gets a virtual memory space of 4 G (addressed with a 32 bit pointer). Most of these pages do not exist. Attempting to read from or write to any of them would cause a MMU-CPU exception, or 'page fault'.

If that page fault was you, trying to use a page of memory that has been swapped out, Linux will reload that page from disk, and rerun the instruction that generated the page-fault, as though there never was a problem (just an unexplained delay). In this way, a 16 MB machine can have a 64 M footprint (or more).

The ISA bus, is not inside the CPU, so DMA may be limited to the first 16 M of RAM. Other constraints might effect how much of the 4 G space, you are actually allowed to control.

Any page can be moved (mapped) to any page location - instantly - and can appear in several places. Pages can be marked for read / write / execute, and all page faults get trapped and interpreted.

Program text and data files get reloaded from their original files (usually :-), but data in memory doesn't have an original file, so it gets written to the swap file. This happens in units of 4K pages.

Programs go through 'modes', such as startup_mode, redraw_mode, reformat_document_mode. Each activity will have a list of relevent 'c' functions, scattered around the executable, and in dynamically linked libraries. Each activity will tend to look at certain pages of data. Some data pages might be used every time a key is pressed, other might only be used during program startup, then never used again until closedown.

The swapper tries to keep the most frequently accessed pages loaded, at the expense of the least recently used. Swap space is a partition or a file, for the swapper to write and read to.

Other CPU's, with their internal/external MMU's might have 2K pages instead of 4K pages, but the result is much the same. Except that the granularity is different. This may effect applications differently, depending on how the programmers designed it, EG a linked list of objects might be scattered across several 4K pages. Loading 2K pages might be faster, or slower in other circumstances.

In the olden days, and with mainframes, complete processes were swapped in and out in entirity. This makes sense, if you think you can complete the task in the available time + data. But it can be inefficient, moving large chunks of data when 4K or even 1K might be better. Paged memory is better for interactive use, but everybody still calls it swap space.