DragonFly BSD
DragonFly kernel List (threaded) for 2010-02
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

[no subject]


ne.com>	 <201002080636.o186aKex057203@apollo.backplane.com> <95250f81002080232w6235a12ar7ce3291349835890@mail.gmail.com> <201002081732.o18HWTL1001721@apollo.backplane.com> <4B705D44.80104@yberwaffe.com>
From: Matthew Dillon <dillon@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@crater.dragonflybsd.org>
List-Subscribe: <mailto:kernel-request@crater.dragonflybsd.org?body=subscribe>
List-Unsubscribe: <mailto:kernel-request@crater.dragonflybsd.org?body=unsubscribe>
List-Help: <mailto:kernel-request@crater.dragonflybsd.org?body=help>
List-Owner: <mailto:owner-kernel@crater.dragonflybsd.org>
Sender: kernel-errors@crater.dragonflybsd.org
Errors-To: kernel-errors@crater.dragonflybsd.org
Lines: 36
X-Trace: 1265660476 crater_reader.dragonflybsd.org 884
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.


[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]