linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Josef Bacik <josef@redhat.com>
To: Shaohua Li <shaohua.li@intel.com>
Cc: Josef Bacik <josef@redhat.com>,
	"linux-btrfs@vger.kernel.org" <linux-btrfs@vger.kernel.org>,
	"chris.mason@oracle.com" <chris.mason@oracle.com>
Subject: Re: [PATCH]btrfs: speed up extent_io tree search
Date: Tue, 20 Apr 2010 22:11:01 -0400	[thread overview]
Message-ID: <20100421021100.GA5827@localhost.localdomain> (raw)
In-Reply-To: <20100421014817.GA12755@sli10-desk.sh.intel.com>

On Wed, Apr 21, 2010 at 09:48:17AM +0800, Shaohua Li wrote:
> On Tue, Apr 20, 2010 at 10:39:01PM +0800, Josef Bacik wrote:
> > On Tue, Apr 20, 2010 at 05:21:58PM +0800, Shaohua Li wrote:
> > > searching extent_io_tree is frequently used and tooks a lot of cpu time.
> > > We could cache last found extent_state to skip some full search. In my
> > > test, the hit rate is from 30% to 70% depending on different workload,
> > > which can speed up the search.
> > > 
> > > Signed-off-by: Shaohua Li <shaohua.li@intel.com>
> > > 
> > > diff --git a/fs/btrfs/extent_io.c b/fs/btrfs/extent_io.c
> > > index d2d0368..645f00c 100644
> > > --- a/fs/btrfs/extent_io.c
> > > +++ b/fs/btrfs/extent_io.c
> > > @@ -110,6 +110,7 @@ void extent_io_tree_init(struct extent_io_tree *tree,
> > >  	spin_lock_init(&tree->lock);
> > >  	spin_lock_init(&tree->buffer_lock);
> > >  	tree->mapping = mapping;
> > > +	tree->cached_state = NULL;
> > >  }
> > >  
> > >  static struct extent_state *alloc_extent_state(gfp_t mask)
> > > @@ -135,6 +136,22 @@ static struct extent_state *alloc_extent_state(gfp_t mask)
> > >  	return state;
> > >  }
> > >  
> > > +static void remove_cached_extent(struct extent_io_tree *tree,
> > > +	struct extent_state *state)
> > > +{
> > > +	if (!tree->cached_state)
> > > +		return;
> > > +	if (tree->cached_state == state)
> > > +		tree->cached_state = NULL;
> > > +}
> > > +
> > > +static void merge_cached_extent(struct extent_io_tree *tree,
> > > +	struct extent_state *first, struct extent_state *last)
> > > +{
> > > +	if (tree->cached_state == first || tree->cached_state == last)
> > > +		tree->cached_state = first;
> > > +}
> > > +
> > >  static void free_extent_state(struct extent_state *state)
> > >  {
> > >  	if (!state)
> > > @@ -188,6 +205,12 @@ static struct rb_node *__etree_search(struct extent_io_tree *tree, u64 offset,
> > >  	struct rb_node *orig_prev = NULL;
> > >  	struct tree_entry *entry;
> > >  	struct tree_entry *prev_entry = NULL;
> > > +	struct tree_entry *cached_entry =
> > > +				(struct tree_entry *)tree->cached_state;
> > > +
> > > +	if (likely(cached_entry && offset >= cached_entry->start &&
> > > +		offset <= cached_entry->end))
> > > +		return &cached_entry->rb_node;
> > >  
> > >  	while (n) {
> > >  		entry = rb_entry(n, struct tree_entry, rb_node);
> > > @@ -198,8 +221,10 @@ static struct rb_node *__etree_search(struct extent_io_tree *tree, u64 offset,
> > >  			n = n->rb_left;
> > >  		else if (offset > entry->end)
> > >  			n = n->rb_right;
> > > -		else
> > > +		else {
> > > +			tree->cached_state = (struct extent_state *)entry;
> > >  			return n;
> > > +		}
> > >  	}
> > >  
> > >  	if (prev_ret) {
> > > @@ -313,6 +338,7 @@ static int merge_state(struct extent_io_tree *tree,
> > >  			merge_cb(tree, state, other);
> > >  			state->start = other->start;
> > >  			other->tree = NULL;
> > > +			merge_cached_extent(tree, state, other);
> > >  			rb_erase(&other->rb_node, &tree->state);
> > >  			free_extent_state(other);
> > >  		}
> > > @@ -325,6 +351,7 @@ static int merge_state(struct extent_io_tree *tree,
> > >  			merge_cb(tree, state, other);
> > >  			other->start = state->start;
> > >  			state->tree = NULL;
> > > +			merge_cached_extent(tree, other, state);
> > >  			rb_erase(&state->rb_node, &tree->state);
> > >  			free_extent_state(state);
> > >  			state = NULL;
> > > @@ -473,6 +500,7 @@ static int clear_state_bit(struct extent_io_tree *tree,
> > >  		wake_up(&state->wq);
> > >  	if (delete || state->state == 0) {
> > >  		if (state->tree) {
> > > +			remove_cached_extent(tree, state);
> > >  			clear_state_cb(tree, state, state->state);
> > >  			rb_erase(&state->rb_node, &tree->state);
> > >  			state->tree = NULL;
> > > diff --git a/fs/btrfs/extent_io.h b/fs/btrfs/extent_io.h
> > > index bbab481..e60b367 100644
> > > --- a/fs/btrfs/extent_io.h
> > > +++ b/fs/btrfs/extent_io.h
> > > @@ -89,6 +89,7 @@ struct extent_io_tree {
> > >  	spinlock_t lock;
> > >  	spinlock_t buffer_lock;
> > >  	struct extent_io_ops *ops;
> > > +	struct extent_state *cached_state;
> > >  };
> > >  
> > >  struct extent_state {
> > 
> > Sorry I saw this earlier but then forgot about it.  So instead of doing a
> > per-tree thing, which will end up with misses if somebody else tries to search
> > the tree for a different offset, you will want to do something like this
> > 
> > http://git.kernel.org/?p=linux/kernel/git/mason/btrfs-unstable.git;a=commit;h=2ac55d41b5d6bf49e76bc85db5431240617e2f8f
> > 
> > So that way _anybody_ who does a search will have a cached state, and so all
> > subsequent searches won't be needed, instead of only working for the first guy
> > who gets their state cached.  Thanks,
> Hmm, the patch you pointed out is already in upstream but I still saw the search
> takes a lot of CPU.
> 

I've probably missed some places where we could be using cached extent states, I
wasn't terribly thorough when I was checking.  It may be good to instrument the
cases where we come into test/clear/set bits and we not end up using the cached
state to see where the trouble spots are.  Thanks,

Josef

  reply	other threads:[~2010-04-21  2:11 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-04-20  9:21 [PATCH]btrfs: speed up extent_io tree search Shaohua Li
2010-04-20 14:39 ` Josef Bacik
2010-04-21  1:48   ` Shaohua Li
2010-04-21  2:11     ` Josef Bacik [this message]
2010-04-21  3:10       ` Shaohua Li
2010-04-21 13:42         ` Josef Bacik

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=20100421021100.GA5827@localhost.localdomain \
    --to=josef@redhat.com \
    --cc=chris.mason@oracle.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=shaohua.li@intel.com \
    /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).