Re: 2.6.35 performance results

[Steven Pratt <slpratt@austin.ibm.com>]

Steven Pratt wrote:
> 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;
>>  
This did not seem to help, in fact we regressed more with COW enabled.. 
One thing to note, the last 2 sets of runs in the history graphs were 
actually run by Keith and he used stock kernel trees. For my recreate, I 
pulled the latest btrfs-unstable which is based on a 2.6.34 tree. Should 
I retest this on stock 2.6.35?  The high time in 
btrfs_start_one_delalloc_inode still exists.

Full results can be found here:
http://btrfs.boxacle.net/repository/raid/perftest/perfpatch/perfpatch.html

128 thread random write test that shows the problem:

http://btrfs.boxacle.net/repository/raid/perftest/perfpatch/perfpatch_Large_file_random_writes._num_threads=128.html

Steve


>
> -- 
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html