[lkml]   [2000]   [Oct]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: TODO list for new VM (oct 2000)
    :On Mon, 2 Oct 2000, Rik van Riel wrote:
    :> On Mon, 2 Oct 2000, Linus Torvalds wrote:
    :> > Why do you apparently ignore the fact that page-out write-back
    :> > performance is horribly crappy because it always starts out
    :> > doing synchronous writes?
    :> Because it is fixed in the patch I mailed yesterday?
    :One small warning though. Please don't apply that patch
    :yet because I fixed 3 more small problems today. I'll
    :send you an updated patch...

    My experience with FreeBSD's asynchronous paging
    is that you have to carefully limit the number of
    I/O's you queue at once. Or, more specifically, you
    have to limit the seeking load the async pageouts
    place on the system.

    The performance curve from the point of user processes
    in the system looks like a bell, while the paging
    performance looks like a log curve (increased performance
    with diminishing returns)... if you queue too few
    pages (degenerate into synchronous paging), you have low
    paging performance and high user process performance,
    but you can't clean pages fast enough in a heavily loaded
    system. If you queue too many pages at once, you have
    high paging performance (but with diminishing returns)
    and low user process performance due to the seeking
    load you've placed on the disk. Excessive seeking
    from pageouts will ruin the disk's performance from
    the point of view of other processes in the system.

    FreeBSD has a sysctl variable called vm.max_page_launder
    which limits the number of pages the pageout daemon
    will queue to I/O at once. The default is 32. Numbers
    between 16 and 32 were found to fit the sweet spot of
    the curve the best. Numbers lower then 16 reduced
    system performance because potentially contiguous pageouts
    would get split (causing more seeking rather then less when
    mixed with I/O initiated from user processes), and numbers
    higher then 32 reduced user process performance due to the
    additional seeking from the queued pageouts.

    The sysadmin can adjust the value to effectively give
    paging more or less priority. A smaller number reduces
    paging performance but increasing system performance
    for other processes (though anything less then 4 will
    reduce performance for everyone). A higher number
    increases paging performance at the cost of system
    performance for other processes. Virtually all FreeBSD
    installations that I know about leave the sysctl variable

    Note that the performance bell holds true whether you
    sort disk requests or not, the whole bell simply moves up
    or down on the graph.

    There are a number of things that can be done to mitigate
    the seeking issue, which I discussed with Rik a few months
    ago. The jist of it, though, is that there is a trade-off
    between page-in and page-out performance based on how you
    try to cluster swap allocation. FreeBSD clusters swap
    allocations to optimize page-out performance at the cost
    of page-in performance and that seems to work very
    well under heavy system loads.

    Matthew Dillon
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 12:39    [W:0.023 / U:17.060 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site