Re: [PATCH] Btrfs: allocate the free space by the existed max extent size when ENOSPC

[Miao Xie <miaox@cn.fujitsu.com>]

On 	thu, 29 Aug 2013 14:45:10 +0200, David Sterba wrote:
> On Thu, Aug 29, 2013 at 01:47:38PM +0800, Miao Xie wrote:
>> By the current code, if the requested size is very large, and all the extents
>> in the free space cache are small, we will waste lots of the cpu time to cut
>> the requested size in half and search the cache again and again until it gets
>> down to the size the allocator can return. In fact, we can know the max extent
>> size in the cache after the first search, so we needn't cut the size in half
>> repeatedly, and just use the max extent size directly. This way can save
>> lots of cpu time and make the performance grow up when there are only fragments
>> in the free space cache.
>>
>> According to my test, if there are only 4KB free space extents in the fs,
>> and the total size of those extents are 256MB, we can reduce the execute
>> time of the following test from 5.4s to 1.4s.
>>   dd if=/dev/zero of=<testfile> bs=1MB count=1 oflag=sync
> 
> Sounds like a good improvement! Can you please post the test? Fragmented
> free space is nothing uncommon, so I guess aging the filesystem for a
> while works as well and there the improvement would show up in reduced
> cpu time.

# mkfs.btrfs -f -b 1g <dev>
# mount <dev> <mnt>
# cd <mnt>
# i=0
# while [ 1 ];
> do
> 	fallocate -o 0 -l 1M tmpfile_1M_$i
> 	if [ $? -ne 0 ]
> 	then
> 		break
> 	fi
> 	i=$((i+1))
> done
# dd if=/dev/zero of=tmpfile_4K bs=4K oflag=sync
# rm -f tmpfile_1M_{0..511}
# i=0
# while [ 1 ];
> do
> 	fallocate -o 0 -l 4K fragmented_file_4K_$i
> 	if [ $? -ne 0 ]
> 	then
> 		break
> 	fi
> 	i=$((i+1))
> done
# i=0
# while [ 1 ];
> do
> 	rm -f fragmented_file_4K_$i
> 	i=$((i+2))
> done

Now, we have a fs with 4K-fragmented free space, the free space is 256MB in total.
then, we can do

# dd if=/dev/zero of=<testfile> bs=1MB count=1 oflag=sync

Thanks
Miao