linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Liu Bo <bo.li.liu@oracle.com>
To: linux-btrfs@vger.kernel.org
Subject: [PATCH v7 02/13] Btrfs: improve the delayed refs process in rm case
Date: Mon, 14 Oct 2013 12:59:44 +0800	[thread overview]
Message-ID: <1381726796-27191-3-git-send-email-bo.li.liu@oracle.com> (raw)
In-Reply-To: <1381726796-27191-1-git-send-email-bo.li.liu@oracle.com>

While removing a file with dedup extents, we could have a great number of
delayed refs pending to process, and these refs refer to droping
a ref of the extent, which is of BTRFS_DROP_DELAYED_REF type.

But in order to prevent an extent's ref count from going down to zero when
there still are pending delayed refs, we first select those "adding a ref"
ones, which is of BTRFS_ADD_DELAYED_REF type.

So in removing case, all of our delayed refs are of BTRFS_DROP_DELAYED_REF type,
but we have to walk all the refs issued to the extent to find any
BTRFS_ADD_DELAYED_REF types and end up there is no such thing, and then start
over again to find BTRFS_DROP_DELAYED_REF.

This is really unnecessary, we can improve this by tracking how many
BTRFS_ADD_DELAYED_REF refs we have and search by the right type.

Signed-off-by: Liu Bo <bo.li.liu@oracle.com>
---
 fs/btrfs/delayed-ref.c |   10 ++++++++++
 fs/btrfs/delayed-ref.h |    3 +++
 fs/btrfs/extent-tree.c |   17 ++++++++++++++++-
 3 files changed, 29 insertions(+), 1 deletions(-)

diff --git a/fs/btrfs/delayed-ref.c b/fs/btrfs/delayed-ref.c
index b0d5d79..9596649 100644
--- a/fs/btrfs/delayed-ref.c
+++ b/fs/btrfs/delayed-ref.c
@@ -543,6 +543,10 @@ update_existing_head_ref(struct btrfs_delayed_ref_node *existing,
 	 * update the reference mod on the head to reflect this new operation
 	 */
 	existing->ref_mod += update->ref_mod;
+
+	WARN_ON_ONCE(update->ref_mod > 1);
+	if (update->ref_mod == 1)
+		existing_ref->add_cnt++;
 }
 
 /*
@@ -604,6 +608,12 @@ static noinline void add_delayed_ref_head(struct btrfs_fs_info *fs_info,
 	head_ref->must_insert_reserved = must_insert_reserved;
 	head_ref->is_data = is_data;
 
+	/* track added ref, more comments in select_delayed_ref() */
+	if (count_mod == 1)
+		head_ref->add_cnt = 1;
+	else
+		head_ref->add_cnt = 0;
+
 	INIT_LIST_HEAD(&head_ref->cluster);
 	mutex_init(&head_ref->mutex);
 
diff --git a/fs/btrfs/delayed-ref.h b/fs/btrfs/delayed-ref.h
index 70b962c..9377b27 100644
--- a/fs/btrfs/delayed-ref.h
+++ b/fs/btrfs/delayed-ref.h
@@ -84,6 +84,9 @@ struct btrfs_delayed_ref_head {
 	struct list_head cluster;
 
 	struct btrfs_delayed_extent_op *extent_op;
+
+	int add_cnt;
+
 	/*
 	 * when a new extent is allocated, it is just reserved in memory
 	 * The actual extent isn't inserted into the extent allocation tree
diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c
index d58bef1..f5bf1a8 100644
--- a/fs/btrfs/extent-tree.c
+++ b/fs/btrfs/extent-tree.c
@@ -2280,6 +2280,16 @@ select_delayed_ref(struct btrfs_delayed_ref_head *head)
 	struct rb_node *node;
 	struct btrfs_delayed_ref_node *ref;
 	int action = BTRFS_ADD_DELAYED_REF;
+
+	/*
+	 * track the count of BTRFS_ADD_DELAYED_REF,
+	 * in the case that there's no BTRFS_ADD_DELAYED_REF while there're a
+	 * a great number of BTRFS_DROP_DELAYED_REF,
+	 * it'll waste time on searching BTRFS_ADD_DELAYED_REF, usually this
+	 * happens with dedup enabled.
+	 */
+	if (head->add_cnt == 0)
+		action = BTRFS_DROP_DELAYED_REF;
 again:
 	/*
 	 * select delayed ref of type BTRFS_ADD_DELAYED_REF first.
@@ -2294,8 +2304,11 @@ again:
 				rb_node);
 		if (ref->bytenr != head->node.bytenr)
 			break;
-		if (ref->action == action)
+		if (ref->action == action) {
+			if (action == BTRFS_ADD_DELAYED_REF)
+				head->add_cnt--;
 			return ref;
+		}
 		node = rb_prev(node);
 	}
 	if (action == BTRFS_ADD_DELAYED_REF) {
@@ -2371,6 +2384,8 @@ static noinline int run_clustered_refs(struct btrfs_trans_handle *trans,
 			 * there are still refs with lower seq numbers in the
 			 * process of being added. Don't run this ref yet.
 			 */
+			if (ref->action == BTRFS_ADD_DELAYED_REF)
+				locked_ref->add_cnt++;
 			list_del_init(&locked_ref->cluster);
 			btrfs_delayed_ref_unlock(locked_ref);
 			locked_ref = NULL;
-- 
1.7.7


  parent reply	other threads:[~2013-10-14  5:01 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-10-14  4:59 [RFC PATCH v7 00/13] Online(inband) data deduplication Liu Bo
2013-10-14  4:59 ` [PATCH v7 01/13] Btrfs: skip merge part for delayed data refs Liu Bo
2013-10-14  4:59 ` Liu Bo [this message]
2013-10-22 20:58   ` [PATCH v7 02/13] Btrfs: improve the delayed refs process in rm case Josef Bacik
2013-10-14  4:59 ` [PATCH v7 03/13] Btrfs: introduce a head ref rbtree Liu Bo
2013-10-14  4:59 ` [PATCH v7 04/13] Btrfs: disable qgroups accounting when quata_enable is 0 Liu Bo
2013-12-03 17:13   ` Alex Lyakas
2013-12-03 18:58     ` Alex Lyakas
2013-12-13  5:42     ` Liu Bo
2013-12-13  6:04       ` Liu Bo
2013-10-14  4:59 ` [PATCH v7 05/13] Btrfs: introduce dedup tree and relatives Liu Bo
2013-10-14  4:59 ` [PATCH v7 06/13] Btrfs: introduce dedup tree operations Liu Bo
2013-10-14  4:59 ` [PATCH v7 07/13] Btrfs: introduce dedup state Liu Bo
2013-10-14  4:59 ` [PATCH v7 08/13] Btrfs: make ordered extent aware of dedup Liu Bo
2013-10-14  4:59 ` [PATCH v7 09/13] Btrfs: online(inband) data dedup Liu Bo
2013-10-14  4:59 ` [PATCH v7 10/13] Btrfs: skip dedup reference during backref walking Liu Bo
2013-10-14  4:59 ` [PATCH v7 11/13] Btrfs: don't return space for dedup extent Liu Bo
2013-10-14  4:59 ` [PATCH v7 12/13] Btrfs: fix a crash of dedup ref Liu Bo
2013-10-14  4:59 ` [PATCH v7 13/13] Btrfs: add ioctl of dedup control Liu Bo
2013-10-14  4:59 ` [PATCH v3] Btrfs-progs: add dedup subcommand Liu Bo
2013-10-22 18:55 ` [RFC PATCH v7 00/13] Online(inband) data deduplication Aurelien Jarno
2013-10-23  2:26   ` Liu Bo
2013-10-23  2:36     ` Liu Bo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1381726796-27191-3-git-send-email-bo.li.liu@oracle.com \
    --to=bo.li.liu@oracle.com \
    --cc=linux-btrfs@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).