| Message ID | 1385139163-7539-1-git-send-email-fdmanana@gmail.com (mailing list archive) |
|---|---|
| State | Superseded, archived |
| Headers | show |
On Fri, Nov 22, 2013 at 04:52:43PM +0000, Filipe David Borba Manana wrote: > After an ordered extent completes, don't blindly reset the > inode's ordered tree last accessed ordered extent pointer. > > While running the xfstests I noticed that about 29% of the > time the ordered extent to which tree->last pointed was not > the same as our just completed ordered extent. After that I > ran the following sysbench test (after a prepare phase) and > noticed that about 68% of the time tree->last pointed to > a different ordered extent too. > > sysbench --test=fileio --file-num=32 --file-total-size=4G \ > --file-test-mode=rndwr --num-threads=512 \ > --file-block-size=32768 --max-time=60 --max-requests=0 run > > Therefore reset tree->last on ordered extent removal only if > it pointed to the ordered extent we're removing from the tree. > Well this is excellent, how much does it affect performance tho? I'm still going to take it, I'd just like to know how big of an impact it makes. Thanks, Josef -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/fs/btrfs/ordered-data.c b/fs/btrfs/ordered-data.c index 69582d5..b8c2ded 100644 --- a/fs/btrfs/ordered-data.c +++ b/fs/btrfs/ordered-data.c @@ -520,7 +520,8 @@ void btrfs_remove_ordered_extent(struct inode *inode, spin_lock_irq(&tree->lock); node = &entry->rb_node; rb_erase(node, &tree->tree); - tree->last = NULL; + if (tree->last == node) + tree->last = NULL; set_bit(BTRFS_ORDERED_COMPLETE, &entry->flags); spin_unlock_irq(&tree->lock);
After an ordered extent completes, don't blindly reset the inode's ordered tree last accessed ordered extent pointer. While running the xfstests I noticed that about 29% of the time the ordered extent to which tree->last pointed was not the same as our just completed ordered extent. After that I ran the following sysbench test (after a prepare phase) and noticed that about 68% of the time tree->last pointed to a different ordered extent too. sysbench --test=fileio --file-num=32 --file-total-size=4G \ --file-test-mode=rndwr --num-threads=512 \ --file-block-size=32768 --max-time=60 --max-requests=0 run Therefore reset tree->last on ordered extent removal only if it pointed to the ordered extent we're removing from the tree. Signed-off-by: Filipe David Borba Manana <fdmanana@gmail.com> --- fs/btrfs/ordered-data.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)