DragonFly kernel List (threaded) for 2010-02
ne.com> <201002080636.o186aKex057203@apollo.backplane.com> <firstname.lastname@example.org> <201002081732.o18HWTL1001721@apollo.backplane.com> <4B705D44.email@example.com>
From: Matthew Dillon <firstname.lastname@example.org>
Subject: Re: kernel work week of 3-Feb-2010 HEADS UP (interleaved swap test)
Date: Mon, 8 Feb 2010 12:17:33 -0800 (PST)
X-Trace: 1265660476 crater_reader.dragonflybsd.org 884 220.127.116.11
Xref: crater_reader.dragonflybsd.org dragonfly.kernel:14072
:Neat stuff indeed.
:But have you tried a mixed write/read load ???
:That would be closer to a "real" system load.
:Kaiser Jasse -- Authorized Stealth Oracle
swapcache doesn't cache writes. That is, it doesn't make
writes to the filesystem any faster, but there are some
beneficial auxillary effects in a mixed-load environment.
blogbench is a fairly good test of a mixed write/read load. It
basically creates an ever-growing dataset (ultimately blowing out
memory caches) with 100 random readers and 5-10 writers, or
something like that.
Essentially what happens is that write performance stays the
same and read performance goes up considerably, as long as the
dataset can be cached by swapcache. If the entire dataset cannot
be cached by swapcache then you can turn on meta-data caching and
turn off file-data caching and write performance actually goes up
a bit due to the lower meta-data load imposed by the reads (the
reads seek less on the HD).
Typically the write rate is too high for swapcache to be able to
cache the entire data set. It will quickly hit the long term average
write bandwidth limit set for the SSD (vm.swapcache.accrate). If
the write rate is not too high, though, then the swapcache will give
you major improvements in read performance on the read-side of the
equation. Something like blogbench of writes as fast as it can,
of course, so it isn't the best test in the world.