Re: Regression in: [PATCH 4/4] btrfs: qgroup: account shared subtree during snapshot delete

[Qu Wenruo <quwenruo@cn.fujitsu.com>]

Mark Fasheh wrote on 2015/11/05 19:15 -0800:
> On Fri, Nov 06, 2015 at 09:02:13AM +0800, Qu Wenruo wrote:
>>> The same exact code ran in either case before and after your patches, so my
>>> guess is that the issue is actually inside the qgroup code that shouldn't
>>> have been run. I wonder if we even just filled up his memory but never
>>> cleaned the objects. The only other thing I can think of is if
>>> account_leaf_items() got run in a really tight loop for some reason.
>>>
>>> Kmalloc in the way we are using it is not usually a performance issue,
>>> especially if we've been reading off disk in the same process. Ask yourself
>>> this - your own patch series does the same kmalloc for every qgroup
>>> operation. Did you notice a complete and massive performance slowdown like
>>> the one Stefan reported?
>>
>> You're right, such memory allocation may impact performance but not
>> so noticeable, compared to other operations which may kick disk IO,
>> like btrfs_find_all_roots().
>>
>> But at least, enabling qgroup will impact performance.
>>
>> Yeah, this time I has test data now.
>> In a environment with 100 different snapshot, sysbench shows an
>> overall performance drop about 5%, and in some case, up to 7%, with
>> qgroup enabled.
>>
>> Not sure about the kmalloc impact, maybe less than 1% or maybe 2~3%,
>> but at least it's worthy trying to use kmem cache.
>
> Ok cool, what'd you do to generate the snapshots? I can try a similar test
> on one of my machines and see what I get. I'm not surprised that the
> overhead is noticable, and I agree it's easy enough to try things like
> replacing the allocation once we have a test going.
>
> Thanks,
> 	--Mark

Doing fsstress in a subvolume with 4 threads, creating a snapshot of 
that subvolume about every 5 seconds.

And do sysbench inside the 50th snapshot.

Such test takes both overhead of btrfs_find_all_roots() and kmalloc().
So I'm not sure which overhead is bigger.

Thanks,
Qu
>
> --
> Mark Fasheh
>