On Fri, 23 Feb 2007 10:56:17 +0700 Eugene Grosbein wrote:
On Thu, Feb 22, 2007 at 12:37:00PM -0500, Zaphod Beeblebrox wrote:
Peter Jeremy wrote:
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
On Thu, Feb 22, 2007 at 12:37:00PM -0500, Zaphod Beeblebrox wrote:
Peter Jeremy wrote:
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
On 2/21/07, Oliver Fromme [EMAIL PROTECTED] wrote:
Peter Jeremy wrote:
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
Peter Jeremy wrote:
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
(oops... didn't group reply)
-- Forwarded message --
From: Zaphod Beeblebrox [EMAIL PROTECTED]
Date: Feb 20, 2007 2:46 AM
Subject: Re: Abyssmal dump cache efficiency
To: Peter Jeremy [EMAIL PROTECTED]
On 2/17/07, Peter Jeremy [EMAIL PROTECTED] wrote:
I've tried modelling
On 2007-Feb-20 02:47:00 -0500, Zaphod Beeblebrox [EMAIL PROTECTED] wrote:
On 2/17/07, Peter Jeremy [EMAIL PROTECTED] 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
I've been looking into the efficiency of the caching in dump(8) and
it's abyssmal: After instrumenting dump(8) and looking at its access
patterns, it turns out that it typically reads roughly three times as
much data into its cache as it should, whilst using five times as
much RAM as requested.
7 matches
Mail list logo