Re: headsup: swap_pager.c

From: Peter Jeremy (PeterJeremy_at_optushome.com.au)
Date: 08/01/03

  • Next message: Poul-Henning Kamp: "Re: headsup: swap_pager.c" 
    Date: Fri, 1 Aug 2003 18:47:38 +1000
To: Poul-Henning Kamp <phk@phk.freebsd.dk>

    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.
    _______________________________________________
    freebsd-arch@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-arch
    To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"

  • Next message: Poul-Henning Kamp: "Re: headsup: swap_pager.c"

    Relevant Pages