Re: XFS/btrfs performance after IO-less dirty throttling

From: Dave Chinner
Date: Sun Dec 18 2011 - 20:58:12 EST


On Fri, Dec 16, 2011 at 01:16:09PM +0800, Wu Fengguang wrote:
> On Fri, Dec 16, 2011 at 12:25:08PM +0800, Dave Chinner wrote:
> > On Fri, Dec 16, 2011 at 09:53:11AM +0800, Wu Fengguang wrote:
> > > I'm indeed happy that you don't care that much on that regression
> > > introduced by me ;-)
> >
> > Heh.
> >
> > BTW, do these tests run to ENOSPC?
>
> Nope. Shall ENOSPC (performance) be tested?
>
> > > 10829.00 +4.3% 11296.00 TOTAL xfs:xfs_delalloc_enospc
> >
> > This implies that it does.
>
> Not really. The USB key partition size is 7.1GB.
> Even in the fastest 1dd case, only 4GB data is written:

There's a couple of ways this can be tripping ENOSPC during delayed
allocation. Speculative preallocation is the most likely cause given
that for a 4GB file being written sequentially it will try to
preallocate a 4GB chunk for the next delalloc extent....

And by triggering this path, it will force data writeback to occur
through the xfssyncd workqueue. i.e. the writeback behaviour that is
occurring is not what you are expecting it to be - XFS is detecting
a potential ENOSPC problem, and taking steps to flush delalloc data
much faster than writeback is doing.

> wfg@bee /export/writeback% cat fat/UKEY-thresh=100M/xfs-1dd-1-3.2.0-rc3/ls-files
> 131 -rw-rw-r-- 1 root root 4060078080 Dec 8 15:57 /fs/sdb3/zero-1

What's the dd command line you are using?

Cheers,

Dave.
--
Dave Chinner
david@xxxxxxxxxxxxx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/