On Thu, May 03, 2012 at 11:25:28AM +0200, Jan Kara wrote: > On Thu 03-05-12 11:43:11, Wu Fengguang wrote: > > This helps write performance when setting the dirty threshold to tiny numbers. > > > > 3.4.0-rc2 3.4.0-rc2-btrfs4+ > > ------------ ------------------------ > > 96.92 -0.4% 96.54 bay/thresh=1000M/btrfs-100dd-1-3.4.0-rc2 > > 98.47 +0.0% 98.50 bay/thresh=1000M/btrfs-10dd-1-3.4.0-rc2 > > 99.38 -0.3% 99.06 bay/thresh=1000M/btrfs-1dd-1-3.4.0-rc2 > > 98.04 -0.0% 98.02 bay/thresh=100M/btrfs-100dd-1-3.4.0-rc2 > > 98.68 +0.3% 98.98 bay/thresh=100M/btrfs-10dd-1-3.4.0-rc2 > > 99.34 -0.0% 99.31 bay/thresh=100M/btrfs-1dd-1-3.4.0-rc2 > > ==> 88.98 +9.6% 97.53 bay/thresh=10M/btrfs-10dd-1-3.4.0-rc2 > > ==> 86.99 +13.1% 98.39 bay/thresh=10M/btrfs-1dd-1-3.4.0-rc2 > > ==> 2.75 +2442.4% 69.88 bay/thresh=1M/btrfs-10dd-1-3.4.0-rc2 > > ==> 3.31 +2634.1% 90.54 bay/thresh=1M/btrfs-1dd-1-3.4.0-rc2 > > > > Signed-off-by: Fengguang Wu <fengguang.wu@xxxxxxxxx> > > --- > > fs/btrfs/disk-io.c | 3 ++- > > 1 file changed, 2 insertions(+), 1 deletion(-) > > > > --- linux-next.orig/fs/btrfs/disk-io.c 2012-05-02 14:04:00.989262395 +0800 > > +++ linux-next/fs/btrfs/disk-io.c 2012-05-02 14:04:01.773262414 +0800 > > @@ -930,7 +930,8 @@ static int btree_writepages(struct addre > > > > /* this is a bit racy, but that's ok */ > > num_dirty = root->fs_info->dirty_metadata_bytes; > > - if (num_dirty < thresh) > > + if (num_dirty < min(thresh, > > + global_dirty_limit << (PAGE_CACHE_SHIFT-2))) > > return 0; > > } > > return btree_write_cache_pages(mapping, wbc); > Frankly, that whole condition on WB_SYNC_NONE in btree_writepages() looks > like a hack. I think we also had problems with this condition when we tried > to change b_more_io list handling. I found rather terse commit message > explaining the code: > Btrfs: Limit btree writeback to prevent seeks It is definitely a hack ;) The basic point is that once we write a metadata block, we have to cow it for any future changes. So writing the metadata has a pretty big impact on performance, and I'd rather write everything else that is dirty first. When that code was added I was finding the metadata going to disk very soon under memory pressure. I'm open to any ideas on this one. -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
