Fwd: Abyssmal dump cache efficiency

Peter Jeremy peterjeremy at optushome.com.au
Tue Feb 20 18:21:16 UTC 2007


On 2007-Feb-20 02:47:00 -0500, Zaphod Beeblebrox <zbeeble at gmail.com> wrote:
>On 2/17/07, Peter Jeremy <peterjeremy at optushome.com.au> wrote:
>>I've tried modelling a unified cache along the NetBSD line and there
>>appears to be a massive improvement in cache performance.  It's unclear
>>how much of an improvement this will give in overall performance but
>>not physically reading data from disk must be faster than reading it.
>
>This squares perfectly with my recent observation that while runing some
>combination of "dump | restore" that the dump disks incur 2 to 3 times more
>I/O (reading) than the restore disks.  Now... for "performance" I was using
>the cache function --- maybe the cache is actually a detriment.

The limited testing I've done suggests that 32MB cache gives you a
10-20% improvement in dump speed.  This would heavily dependent on
the disk I/O performance - a slow CPU running PIO might be better
off without caching.

I've found that you do get a worthwhile improvement in dump|restore
performance by introducing a large (10's of MB) fifo between them.
This helps reduce synchronisation between dump and restore (so that
dump can continue to read whilst restore is busy writing a batch of
small files and vice versa).  There's a suitable port but I can't
recall the name because I wrote my own.

>>I believe it would be worthwhile creating a todo item to investigate
>>this more thoroughly.

Note that I think that fixing this is a weekend job, rather than a SoC
project.

-- 
Peter Jeremy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20070220/ccd1a505/attachment.pgp


More information about the freebsd-hackers mailing list