linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Steven Pratt <slpratt@austin.ibm.com>
To: Chris Mason <chris.mason@oracle.com>,
	linux-btrfs <linux-btrfs@vger.kernel.org>
Subject: Re: 2.6.35 performance results
Date: Sat, 21 Aug 2010 10:25:59 -0500	[thread overview]
Message-ID: <4C6FF007.3080800@austin.ibm.com> (raw)
In-Reply-To: <20100819010031.GI5854@think>

Chris Mason wrote:
> On Mon, Aug 16, 2010 at 04:51:12PM -0500, Steven Pratt wrote:
>   
>> Chris Mason wrote:
>>     
>>>> This changeset introduced "btrfs_start_one_delalloc_inode" in
>>>> http://git.kernel.org/?p=linux/kernel/git/mason/btrfs-unstable.git;a=commitdiff;h=5da9d01b66458b180a6bee0e637a1d0a3effc622
>>>>
>>>> In heavy write workloads this new function is now dominating the profiles:
>>>>
>>>> samples  %        app name                 symbol name
>>>> 8914973  65.1261  btrfs.ko                 btrfs_start_one_delalloc_inode
>>>>         
>>> Hi Steve,
>>>
>>> I think I know why this is a problem and how to fix it, but I'm having a
>>> trouble reproducing this exact setup.  Which of your tests was this
>>> oprofile from?
>>>       
>> 128 thread random write.  With or without nocow option.
>>     
>
> Ok, I haven't managed to reproduce your problem exactly, but this is
> faster for me here.  Could you please give it a try:
>   
Was out on vacation.  Test is running now. Should have results by 
uploaded by Monday.

Steve

> >From 8e965331de749c39f3781d581b55d2c207de060f Mon Sep 17 00:00:00 2001
> From: Chris Mason <chris.mason@oracle.com>
> Date: Wed, 18 Aug 2010 13:31:27 -0400
> Subject: [PATCH] Btrfs: don't trigger delayed allocation throttling as often
>
> We reserve metadata space based on the number of delayed allocation
> extents that are currently pending.  As we run out of space, we start
> forcing writeback to turn those reservations into physical extents.
>
> The reservations are based on some worst case math, so the sooner we
> turn them into real blocks, the better off we are.
>
> But, the writeback is being forced too soon and too often.  This fixes
> things to be less aggressive.
>
> Signed-off-by: Chris Mason <chris.mason@oracle.com>
> ---
>  fs/btrfs/extent-tree.c |    7 ++++++-
>  1 files changed, 6 insertions(+), 1 deletions(-)
>
> diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c
> index 32d0940..55e1ee0 100644
> --- a/fs/btrfs/extent-tree.c
> +++ b/fs/btrfs/extent-tree.c
> @@ -3681,6 +3681,7 @@ int btrfs_delalloc_reserve_metadata(struct inode *inode, u64 num_bytes)
>  	struct btrfs_root *root = BTRFS_I(inode)->root;
>  	struct btrfs_block_rsv *block_rsv = &root->fs_info->delalloc_block_rsv;
>  	u64 to_reserve;
> +	u64 max_reserve;
>  	int nr_extents;
>  	int retries = 0;
>  	int ret;
> @@ -3717,7 +3718,11 @@ again:
>  
>  	block_rsv_add_bytes(block_rsv, to_reserve, 1);
>  
> -	if (block_rsv->size > 512 * 1024 * 1024)
> +	/* 10% or 2GB */
> +	max_reserve = min_t(u64, 2ULL * 1024 * 1024 * 1024,
> +		    div_factor(root->fs_info->fs_devices->total_rw_bytes, 1));
> +
> +	if (block_rsv->size > max_reserve)
>  		shrink_delalloc(NULL, root, to_reserve);
>  
>  	return 0;
>   


  reply	other threads:[~2010-08-21 15:25 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-08-06 18:44 2.6.35 performance results Steven Pratt
2010-08-06 18:58 ` Chris Mason
2010-08-16 20:04 ` Chris Mason
2010-08-16 21:51   ` Steven Pratt
2010-08-19  1:00     ` Chris Mason
2010-08-21 15:25       ` Steven Pratt [this message]
2010-08-23 19:13         ` Steven Pratt
2010-08-23 19:33           ` Chris Mason
2010-08-23 20:10             ` Steven Pratt
  -- strict thread matches above, loose matches on Subject: below --
2010-08-08  4:18 A. James Lewis

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=4C6FF007.3080800@austin.ibm.com \
    --to=slpratt@austin.ibm.com \
    --cc=chris.mason@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).