headsup: swap_pager.c

[Peter Jeremy]

On Thu, Jul 31, 2003 at 11:19:31PM +0200, Poul-Henning Kamp wrote:
>Another thing is that striping does not belong in the swap_pager in
>the first place, we have CCD and similar pieces of code for that.

Can (does) the swap striping code gain any performance advantage by
knowing more about the paging system I/O behaviour than a general
purpose striping tool would?

>The new layout will allocate the devices sequentially in the "virtual
>swapdevice" and allocation will (for now) be round robin between
>the devices.  Later I would like to implement load based device
>selection (ie: pick the device with the lowest recent average access
>time).

My gut feeling is that the paging allocation algorithm has room for
improvement[1].  I'm not sure that allocating based on disk busyness
is necessarily the right direction.

AFAIK, FreeBSD frees the backing swap page if the page in memory is
modified.  This means that a backing page is written once and read
probably a fairly small number of times.  The allocation algorithm
needs to optimise performance across both the write and subsequent
read(s).  Measuring disk busyness over a short period will tend to
optimise the write allocation but have little impact on the reads.
Using a longer period runs the risk that paging spikes can saturate
a disk in the short term.

>If disk striping is necessary for the disks used for swap-space,
>do it with ccd(4) and call swapon on that.

Is the intent to have the paging subsystem spread page allocations
across the available space or preferentially allocate from one end?
In the former case, I don't believe striping has any advantages over
concatenation.  (Though I believe the latter may improve paging
performance in the case where only a small part of the swap space is
in use - which is probably the most common case).

Peter

[1] Based on using X, Mozilla and OpenOffice simultaneously on a system
    with only 128MB RAM.