All of lore.kernel.org
 help / color / mirror / Atom feed
From: Li Zefan <lizf@cn.fujitsu.com>
To: Josef Bacik <josef@redhat.com>
Cc: linux-btrfs@vger.kernel.org
Subject: Re: [PATCH] Btrfs: don't be as aggressive about using bitmaps
Date: Mon, 21 Mar 2011 10:34:31 +0800	[thread overview]
Message-ID: <4D86B937.7080905@cn.fujitsu.com> (raw)
In-Reply-To: <1300479538-4385-1-git-send-email-josef@redhat.com>

04:18, Josef Bacik wrote:
> We have been creating bitmaps for small extents unconditionally forever.  This
> was great when testing to make sure the bitmap stuff was working, but is
> overkill normally.  So instead of always adding small chunks of free space to
> bitmaps, only start doing it if we go past half of our extent threshold.  This
> will keeps us from creating a bitmap for just one small free extent at the front
> of the block group, and will make the allocator a little faster as a result.
> Thanks,
> 

I was wondering this strategy when reading the code, so this patch
looks good to me.

Just a small nit:

> Signed-off-by: Josef Bacik <josef@redhat.com>
> ---
>  fs/btrfs/free-space-cache.c |   19 ++++++++++++++++---
>  1 files changed, 16 insertions(+), 3 deletions(-)
> 
> diff --git a/fs/btrfs/free-space-cache.c b/fs/btrfs/free-space-cache.c
> index 63776ae..7a808d7 100644
> --- a/fs/btrfs/free-space-cache.c
> +++ b/fs/btrfs/free-space-cache.c
> @@ -1287,9 +1287,22 @@ static int insert_into_bitmap(struct btrfs_block_group_cache *block_group,
>  	 * If we are below the extents threshold then we can add this as an
>  	 * extent, and don't have to deal with the bitmap
>  	 */
> -	if (block_group->free_extents < block_group->extents_thresh &&
> -	    info->bytes > block_group->sectorsize * 4)
> -		return 0;
> +	if (block_group->free_extents < block_group->extents_thresh) {
> +		/*
> +		 * If this block group has some small extents we don't want to
> +		 * use up all of our free slots in the cache with them, we want
> +		 * to reserve them to larger extents, however if we have plent
> +		 * of cache left then go ahead an dadd them, no sense in adding
> +		 * the overhead of a bitmap if we don't have to.
> +		 */
> +		if (info->bytes < block_group->sectorsize * 4) {

This also changes how we define a small extent (from 4 sectorsize to 3).
Is it intended?

> +			if ((block_group->free_extents * 2) <=

The parentheses isn't necessary nor help in readability I think.

> +			    block_group->extents_thresh)
> +				return 0;
> +		} else {
> +			return 0;
> +		}
> +	}
>  
>  	/*
>  	 * some block groups are so tiny they can't be enveloped by a bitmap, so


  reply	other threads:[~2011-03-21  2:34 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-03-18 20:18 [PATCH] Btrfs: don't be as aggressive about using bitmaps Josef Bacik
2011-03-21  2:34 ` Li Zefan [this message]
2011-03-21 14:24   ` [PATCH] Btrfs: don't be as aggressive about using bitmaps V2 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=4D86B937.7080905@cn.fujitsu.com \
    --to=lizf@cn.fujitsu.com \
    --cc=josef@redhat.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.