headsup: swap_pager.c

[Poul-Henning Kamp]

In message <20030801084737.GA44755 at cirb503493.alcatel.com.au>, Peter Jeremy wri
tes:
>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?

no.

>>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.

Neither am I, I'm not even sure how relevant it is to optimize this
in the first place, so that's why I plan to do the simple "round robin"
as a first cut.

>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.

The thing you overlook is that often when things gets paged out, the
system is short on memory and therefore more likely to not do anything
productive, whereas when things gets paged in, there are a better chance
of some other process being able to use the CPU time productively.
If we did predictive pageouts like some of the "serious" mainfram OS's
this would be less true.

>>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).

Pulling the internal striping out of the swapper will allow people to
actually experiment with this...

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.