From: Chris Mason <chris.mason@oracle.com>
To: Andi Kleen <andi@firstfloor.org>
Cc: Peter Zijlstra <peterz@infradead.org>,
linux-btrfs <linux-btrfs@vger.kernel.org>,
linux-kernel <linux-kernel@vger.kernel.org>,
linux-fsdevel <linux-fsdevel@vger.kernel.org>
Subject: Re: Btrfs v0.16 released
Date: Thu, 14 Aug 2008 21:25:54 -0400 [thread overview]
Message-ID: <1218763554.15342.460.camel@think.oraclecorp.com> (raw)
In-Reply-To: <20080814211756.GC13814@one.firstfloor.org>
On Thu, 2008-08-14 at 23:17 +0200, Andi Kleen wrote:
> On Thu, Aug 14, 2008 at 05:00:56PM -0400, Chris Mason wrote:
> > Btrfs defaults 57.41 MB/s
Looks like I can get the btrfs defaults up to 64MB/s with some writeback
tweaks.
> > Btrfs dup no csum 74.59 MB/s
>
> With duplications checksums seem to be quite costly (CPU bound?)
>
The async worker threads should be spreading the load across CPUs pretty
well, and even a single CPU could keep up with 100MB/s checksumming.
But, the async worker threads do randomize the IO somewhat because the
IO goes from pdflush -> one worker thread per CPU -> submit_bio. So,
maybe that 3rd thread is more than the drive can handle?
btrfsck tells me the total size of the btree is only 20MB larger with
checksumming on.
> > Btrfs no duplication 76.83 MB/s
> > Btrfs no dup no csum no inline 76.85 MB/s
>
> But without duplication they are basically free here at least
> in IO rate. Seems odd?
>
> Does it compute them twice in the duplication case perhaps?
>
The duplication happens lower down in the stack, they only get done
once.
-chris
next prev parent reply other threads:[~2008-08-15 1:25 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-08-05 19:01 Btrfs v0.16 released Chris Mason
2008-08-07 9:08 ` Peter Zijlstra
2008-08-07 10:34 ` Chris Mason
2008-08-07 14:58 ` Chris Friesen
2008-08-07 15:07 ` tvrtko.ursulin
2008-08-07 9:14 ` Peter Zijlstra
2008-08-07 10:39 ` Chris Mason
[not found] ` <3da3b5b40808070703x4cf49471q6acc00351ba019d7@mail.gmail.com>
2008-08-07 14:06 ` Chris Mason
2008-08-07 18:02 ` Andi Kleen
2008-08-08 18:48 ` Chris Mason
2008-08-08 21:56 ` Andi Kleen
2008-08-09 1:19 ` Theodore Tso
2008-08-09 1:23 ` Andi Kleen
2008-08-09 1:23 ` Andi Kleen
2008-08-09 1:43 ` Theodore Tso
2008-08-09 1:23 ` Andi Kleen
2008-08-14 21:00 ` Chris Mason
2008-08-14 21:17 ` Andi Kleen
2008-08-15 1:25 ` Chris Mason [this message]
2008-08-15 1:39 ` Andi Kleen
2008-08-15 13:00 ` Chris Mason
2008-08-16 19:26 ` Szabolcs Szakacsits
2008-08-18 13:52 ` Chris Mason
2008-08-18 17:37 ` Szabolcs Szakacsits
2008-08-14 23:44 ` Theodore Tso
2008-08-15 1:10 ` Chris Mason
2008-08-15 12:46 ` Chris Mason
2008-08-15 13:45 ` Theodore Tso
2008-08-15 17:52 ` Chris Mason
2008-08-15 19:59 ` Theodore Tso
2008-08-15 20:37 ` Chris Mason
2008-08-16 18:10 ` Chris Mason
2008-08-16 19:27 ` Theodore Tso
-- strict thread matches above, loose matches on Subject: below --
2008-08-07 19:33 btrfs-devel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1218763554.15342.460.camel@think.oraclecorp.com \
--to=chris.mason@oracle.com \
--cc=andi@firstfloor.org \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=peterz@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.