On Fri, 2008-08-15 at 03:39 +0200, Andi Kleen wrote: > > 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? > It was a very confusing use of the word thread. I have the same number of kernel threads running, but the single spindle on the drive has to deal with 3 different streams of writes. The seeks/sec portion of the graph shows a big enough increase in seeks on the duplication run to explain the performance. > > 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. It does, I'll give the test a shot on other hardware too. To be honest I'm pretty happy at matching ext4 with duplication on. The graph shows even writeback and the times from each iteration are fairly consistent. Ext3 and XFS score somewhere between 10-15MB/s on the same test... -chris -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
