[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20080815013934.GE19125@one.firstfloor.org>
Date: Fri, 15 Aug 2008 03:39:34 +0200
From: Andi Kleen <andi@...stfloor.org>
To: Chris Mason <chris.mason@...cle.com>
Cc: Andi Kleen <andi@...stfloor.org>,
Peter Zijlstra <peterz@...radead.org>,
linux-btrfs <linux-btrfs@...r.kernel.org>,
linux-kernel <linux-kernel@...r.kernel.org>,
linux-fsdevel <linux-fsdevel@...r.kernel.org>
Subject: Re: Btrfs v0.16 released
> 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?
You have more threads with duplication?
>
> 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.
Ok was just speculation. The big difference still seems odd.
-Andi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists