No subject

Unknown Unknown
Mon Feb 8 12:19:47 PST 2010


ne.com>	 <201002080636.o186aKex057203 at apollo.backplane.com> <95250f81002080232w6235a12ar7ce3291349835890 at mail.gmail.com> <201002081732.o18HWTL1001721 at apollo.backplane.com> <4B705D44.80104 at yberwaffe.com>
From: Matthew Dillon <dillon at apollo.backplane.com>
Subject: Re: kernel work week of 3-Feb-2010 HEADS UP (interleaved swap test)
Date: Mon, 8 Feb 2010 12:17:33 -0800 (PST)
BestServHost: crater.dragonflybsd.org
List-Post: <mailto:kernel at crater.dragonflybsd.org>
List-Subscribe: <mailto:kernel-request at crater.dragonflybsd.org?body=subscribe>
List-Unsubscribe: <mailto:kernel-request at crater.dragonflybsd.org?body=unsubscribe>
List-Help: <mailto:kernel-request at crater.dragonflybsd.org?body=help>
List-Owner: <mailto:owner-kernel at crater.dragonflybsd.org>
Sender: kernel-errors at crater.dragonflybsd.org
Errors-To: kernel-errors at crater.dragonflybsd.org
Lines: 36
NNTP-Posting-Host: 216.240.41.25
X-Trace: 1265660476 crater_reader.dragonflybsd.org 884 216.240.41.25
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.

					-Matt






More information about the Kernel mailing list