: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...
:...
:regards,
:
:Rik
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
alone.
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.
-Matt
Matthew Dillon
<dillon@backplane.com>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Oct 07 2000 - 21:00:15 EST