xfs
[Top] [All Lists]

Re: [PATCH] xfs: improve xfs_bitmap_empty()

To: Dave Chinner <david@xxxxxxxxxxxxx>
Subject: Re: [PATCH] xfs: improve xfs_bitmap_empty()
From: Jeff Liu <jeff.liu@xxxxxxxxxx>
Date: Tue, 04 Feb 2014 23:10:11 +0800
Cc: Mark Tinguely <tinguely@xxxxxxx>, Eric Sandeen <sandeen@xxxxxxxxxxx>, "xfs@xxxxxxxxxxx" <xfs@xxxxxxxxxxx>
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <20140202215231.GS2212@dastard>
References: <52EBAF91.10608@xxxxxxxxxx> <52EBBC3D.5030507@xxxxxxxxxxx> <52EBC103.5050006@xxxxxxxxxx> <52EBC1AF.6020000@xxxxxxxxxxx> <52EBC67B.7020806@xxxxxxxxxx> <52EBCF12.1020403@xxxxxxx> <52EC6EA0.9000501@xxxxxxxxxx> <20140202215231.GS2212@dastard>
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
On 02/03 2014 05:52 AM, Dave Chinner wrote:
> On Sat, Feb 01, 2014 at 11:48:48AM +0800, Jeff Liu wrote:
>> On 02/01 2014 00:28 AM, Mark Tinguely wrote:
>>> On 01/31/14 09:51, Jeff Liu wrote:
>>>> On 01/31 2014 23:30 PM, Eric Sandeen wrote:
>>>>> On 1/31/14, 9:28 AM, Jeff Liu wrote:
>>>>>> Well, when I looking through our bitmap source, I once thought if
>>>>>> we can replace the current code with the generic bitmap library.
>>>>>> However, our map is uint rather than unsigned long...
>>>>>
>>>>> Technically the unsigned long (pointer) is just the bitmap address,
>>>>> I think.
>>>>
>>>> Yeah, so this might worth to try on long terms.
>>>
>>> The blf_data_map[] is int aligned, not long aligned.
>>> You could reflect the alignment difference in the offset or
>>> change the alignment in the structure.
>>
>> For now, I think we can not simply turn to generic bitmap just because
>> of the alignment difference on 64-bits OS.
> 
> The bitmaps end up on disk (in the log), so replacing the
> implementation with a generic implementation is something we need to
> be very careful about.
> 
> IMO, we should be getting rid of the bitmaps from the
> xfs_buf_log_item first (by moving to a low byte/high byte offset
> range), then we only have to worry about bitmaps when doing log
> recovery after a kernel upgrade on a filesystem with a dirty log.
> 
> Getting rid of the bitmaps also solves a scalability problem with
> large block sizes tracking all the changes in buffer - we burn a
> huge amount of CPU walking bits when logging 64k directory buffers:
> 
> +  21.19%  [kernel]  [k] xfs_dir3_leaf_check_int
> +  12.20%  [kernel]  [k] memcpy
> +   9.29%  [kernel]  [k] xfs_next_bit
> +   5.04%  [kernel]  [k] xfs_buf_offset
> +   3.63%  [kernel]  [k] xfs_buf_item_format
> +   3.59%  [kernel]  [k] xfs_buf_item_size_segment
> 
> The logging of xfs_buf_log_items there is consuming >30% of the CPU
> being used under this workload (xfs_dir3_leaf_check_int() is high
> because this is from a debug kernel.)
> 
> IOWs, we should work to remove the bitmap code from general
> operations first, then replace the remaining legacy log recovery
> code with the generic bitmap implemention....

Sorry for my too late response as I was on vacations.

I only moved a little progress after a quick hacking, but I can see the point
in getting rid of the bitmap, just give me yet a week once I was totally return
to work.


Thanks,
-Jeff

<Prev in Thread] Current Thread [Next in Thread>