linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH] Btrfs: be smarter about dropping things from the tree log
@ 2012-09-28 15:58 Josef Bacik
  2012-09-28 17:45 ` Zach Brown
  0 siblings, 1 reply; 3+ messages in thread
From: Josef Bacik @ 2012-09-28 15:58 UTC (permalink / raw)
  To: linux-btrfs

When we truncate existing items in the tree log we've been searching for
each individual item and removing them.  This is unnecessary churn and
searching, just keep track of the slot we are on and how many items we need
to delete and delete them all at once.  Thanks,

Signed-off-by: Josef Bacik <jbacik@fusionio.com>
---
 fs/btrfs/tree-log.c |   16 ++++++++++++++--
 1 files changed, 14 insertions(+), 2 deletions(-)

diff --git a/fs/btrfs/tree-log.c b/fs/btrfs/tree-log.c
index 4e468a0..90e1c28 100644
--- a/fs/btrfs/tree-log.c
+++ b/fs/btrfs/tree-log.c
@@ -2872,12 +2872,15 @@ static int drop_objectid_items(struct btrfs_trans_handle *trans,
 	int ret;
 	struct btrfs_key key;
 	struct btrfs_key found_key;
+	int start_slot;
+	int del_nr = 0;
 
 	key.objectid = objectid;
 	key.type = max_key_type;
 	key.offset = (u64)-1;
 
 	while (1) {
+		del_nr = 0;
 		ret = btrfs_search_slot(trans, log, &key, path, -1, 1);
 		BUG_ON(ret == 0);
 		if (ret < 0)
@@ -2885,20 +2888,29 @@ static int drop_objectid_items(struct btrfs_trans_handle *trans,
 
 		if (path->slots[0] == 0)
 			break;
-
+next_slot:
 		path->slots[0]--;
+
 		btrfs_item_key_to_cpu(path->nodes[0], &found_key,
 				      path->slots[0]);
 
 		if (found_key.objectid != objectid)
 			break;
 
-		ret = btrfs_del_item(trans, log, path);
+		start_slot = path->slots[0];
+		del_nr++;
+		if (start_slot)
+			goto next_slot;
+
+		ret = btrfs_del_items(trans, log, path, start_slot, del_nr);
 		if (ret)
 			break;
 		btrfs_release_path(path);
 	}
+	if (!ret && del_nr)
+		ret = btrfs_del_items(trans, log, path, start_slot, del_nr);
 	btrfs_release_path(path);
+
 	if (ret > 0)
 		ret = 0;
 	return ret;
-- 
1.7.7.6


^ permalink raw reply related	[flat|nested] 3+ messages in thread

* Re: [PATCH] Btrfs: be smarter about dropping things from the tree log
  2012-09-28 15:58 [PATCH] Btrfs: be smarter about dropping things from the tree log Josef Bacik
@ 2012-09-28 17:45 ` Zach Brown
  2012-10-01 16:47   ` Josef Bacik
  0 siblings, 1 reply; 3+ messages in thread
From: Zach Brown @ 2012-09-28 17:45 UTC (permalink / raw)
  To: Josef Bacik; +Cc: linux-btrfs

> When we truncate existing items in the tree log we've been searching for
> each individual item and removing them.  This is unnecessary churn and
> searching, just keep track of the slot we are on and how many items we need
> to delete and delete them all at once.  Thanks,

(speaking of unnecessary churn :))

> +next_slot:
>  		path->slots[0]--;
> +
>  		btrfs_item_key_to_cpu(path->nodes[0], &found_key,
>  				      path->slots[0]);
>  
>  		if (found_key.objectid != objectid)
>  			break;
>  
> -		ret = btrfs_del_item(trans, log, path);
> +		start_slot = path->slots[0];
> +		del_nr++;
> +		if (start_slot)
> +			goto next_slot;

A linear backwards scan?  Of potentially 64k leaves?

Can you use bin_search() to look for the first key >= [objectid,0,0] in
the leaf?  And probably a single comparison of slot 0 to fast path the
case where the whole leaf contains the object id?

> +		ret = btrfs_del_items(trans, log, path, start_slot, del_nr);
>  		if (ret)
>  			break;
>  		btrfs_release_path(path);
>  	}
> +	if (!ret && del_nr)
> +		ret = btrfs_del_items(trans, log, path, start_slot, del_nr);
>  	btrfs_release_path(path);

You shouldn't have to duplicate deletion and releasing the path if you
wrap the calculation of start_slot and nr in a helper.  Something like:

	nr = find_nr_and_slot_doo_de_doo(, &start_slot);
	if (nr > 0)
		btrfs_del_items(, start_slot, nr);

- z

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [PATCH] Btrfs: be smarter about dropping things from the tree log
  2012-09-28 17:45 ` Zach Brown
@ 2012-10-01 16:47   ` Josef Bacik
  0 siblings, 0 replies; 3+ messages in thread
From: Josef Bacik @ 2012-10-01 16:47 UTC (permalink / raw)
  To: Zach Brown; +Cc: Josef Bacik, linux-btrfs@vger.kernel.org

On Fri, Sep 28, 2012 at 11:45:21AM -0600, Zach Brown wrote:
> > When we truncate existing items in the tree log we've been searching for
> > each individual item and removing them.  This is unnecessary churn and
> > searching, just keep track of the slot we are on and how many items we need
> > to delete and delete them all at once.  Thanks,
> 
> (speaking of unnecessary churn :))
> 
> > +next_slot:
> >  		path->slots[0]--;
> > +
> >  		btrfs_item_key_to_cpu(path->nodes[0], &found_key,
> >  				      path->slots[0]);
> >  
> >  		if (found_key.objectid != objectid)
> >  			break;
> >  
> > -		ret = btrfs_del_item(trans, log, path);
> > +		start_slot = path->slots[0];
> > +		del_nr++;
> > +		if (start_slot)
> > +			goto next_slot;
> 
> A linear backwards scan?  Of potentially 64k leaves?
> 
> Can you use bin_search() to look for the first key >= [objectid,0,0] in
> the leaf?  And probably a single comparison of slot 0 to fast path the
> case where the whole leaf contains the object id?
> 

Yeah I can do that.

> > +		ret = btrfs_del_items(trans, log, path, start_slot, del_nr);
> >  		if (ret)
> >  			break;
> >  		btrfs_release_path(path);
> >  	}
> > +	if (!ret && del_nr)
> > +		ret = btrfs_del_items(trans, log, path, start_slot, del_nr);
> >  	btrfs_release_path(path);
> 
> You shouldn't have to duplicate deletion and releasing the path if you
> wrap the calculation of start_slot and nr in a helper.  Something like:
> 
> 	nr = find_nr_and_slot_doo_de_doo(, &start_slot);
> 	if (nr > 0)
> 		btrfs_del_items(, start_slot, nr);

K, I'll fix that up, thanks.

Josef

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2012-10-01 16:47 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-09-28 15:58 [PATCH] Btrfs: be smarter about dropping things from the tree log Josef Bacik
2012-09-28 17:45 ` Zach Brown
2012-10-01 16:47   ` Josef Bacik

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).