On Fri, Sep 11, 2009 at 04:35:50PM -0500, Steven Pratt wrote: > Chris Mason wrote: > >On Mon, Aug 31, 2009 at 12:49:13PM -0500, Steven Pratt wrote: > >>Better late than never. Finally got this finished up. Mixed bag on > >>this one. BTRFS lags significantly on single threaded. Seems > >>unable to keep IO outstanding to the device. Less that 60% busy on > >>the DM device, compared to 97%+ for all other filesystems. > >>nodatacow helps out, increasing utilization to about 70%, but still > >>trails by a large margin. > > > >Hi Steve, > > > >Jens Axboe did some profiling on his big test rig and I think we found > >the biggest CPU problems. The end result is now setting in the master > >branch of the btrfs-unstable repo. > > > >On his boxes, btrfs went from around 400MB/s streaming writes to 1GB/s > >limit, and we're now tied with XFS while using less CPU time. > > > >Hopefully you will see similar results ;) > Hmmm, well no I didn't. Throughputs at 1 and 128 threads are pretty > much unchanged, although I do see a good CPU savings on the 128 > thread case (with cow). For 16 threads we actually regressed with > cow enabled. > > Results are here: > > http://btrfs.boxacle.net/repository/raid/large_create_test/write-test/1M_odirect_create.html > > I'll try to look more into this next week. > Hmmm, Jens was benchmarking buffered writes, but he was also testing on his new per-bdi write back code. If your next run could be buffered instead of O_DIRECT, I'd be curious to see the results. Thanks, Chris -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
