From: Heming Zhao <heming.zhao@suse.com>
To: Joseph Qi <joseph.qi@linux.alibaba.com>
Cc: ocfs2-devel@lists.linux.dev, ailiop@suse.com
Subject: Re: [PATCH] ocfs2: improve write IO performance when fragmentation is high
Date: Wed, 13 Mar 2024 20:32:12 +0800 [thread overview]
Message-ID: <c94f3dd8-7cc6-4a0c-9073-0bb92e81e863@suse.com> (raw)
In-Reply-To: <70d119b5-53c0-4a92-84ec-9b5053184959@linux.alibaba.com>
On 3/13/24 17:09, Joseph Qi wrote:
>
>
> On 3/13/24 9:34 AM, Heming Zhao wrote:
>> Hi Joseph,
>>
>> Before sending v2 patch, I need to explain ocfs2_find_max_contig_free_bits()
>> for you. See the comment in below.
>>
>> On 3/11/24 19:04, Joseph Qi wrote:
>>>
>>> Hi,
>>>
>>> Please see my comments inline.
>>>
>>> On 3/8/24 9:52 AM, Heming Zhao wrote:
>>>> The group_search function ocfs2_cluster_group_search() should
>>>> bypass groups with insufficient space to avoid unnecessary
>>>> searches.
>>>>
>>>> This patch is particularly useful when ocfs2 is handling huge
>>>> number small files, and volume fragmentation is very high.
>>>> In this case, ocfs2 is busy with looking up available la window
>>>> from //global_bitmap.
>>>>
>>>> This patch introduces a new member in the Group Description (gd)
>>>> struct called 'bg_contig_free_bits', representing the max
>>>> contigous free bits in this gd. When ocfs2 allocates a new
>>>> la window from //global_bitmap, 'bg_contig_free_bits' helps
>>>> expedite the search process.
>>>>
>>>> ... ...
>>>> +/* caller should initialize contig_bits */
>>>> +void ocfs2_find_max_contig_free_bits(void *bitmap,
>>>> + unsigned int total_bits, int start,
>>>> + unsigned int *contig_bits)
>>>> +{
>>>> + int offset, free_bits;
>>>> +
>>>> + while (start < total_bits) {
>>>> + offset = ocfs2_find_next_zero_bit(bitmap, total_bits, start);
>>>> + if (offset == total_bits)
>>>> + break;
>>>> +
>>>> + start = ocfs2_find_next_bit(bitmap, total_bits, offset);
>>>> + free_bits = start - offset;
>>>> + if (*contig_bits < free_bits)
>>>> + *contig_bits = free_bits;
>>>> + }
>>>
>>> Or we can just return the contig_bits. Something like:
>>> unsigned int ocfs2_find_max_contig_free_bits(void *bitmap,
>>> unsigned int total_bits, int start)
>>> {
>>> int offset, start;
>>> unsigned int contig_bits = 0;
>>>
>>> while () {
>>> ...
>>> }
>>>
>>> return contig_bits;
>>> }
>>
>> the input *contig_bits has two jobs:
>> - return the max contigous free bits of bitmap
>> - if *contig_bits is not ZERO, it keeps the max-contig-bits
>> from last search. When the input 'start' not zero
>> (means start from middle of bitmap), the max-contig-bits
>> from latter part of bitmap may smaller than first part.
>> at this case, function should keep & return the input
>> *contig_bits.
>>
>
> IC, I don't think it's a good idea to mix up the 2 responsibilities.
> You've hidden the logic that it may change the input contig_bits (not
> the case of first search).
> You can also implement it something like:
>
> contig_bits = ocfs2_find_max_contig_free_bits();
> if (config_bits > sr_max_contig_bits)
> sr_max_contig_bits = contig_bits;
>
> This will be more explicit for an optimized search.
>
> Thanks,
> Joseph
>
Thanks for the explanation, your code logic is better.
- Heming
next prev parent reply other threads:[~2024-03-13 12:32 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-08 1:52 [PATCH] ocfs2: improve write IO performance when fragmentation is high Heming Zhao
2024-03-11 9:18 ` Joseph Qi
2024-03-11 11:04 ` Joseph Qi
2024-03-12 0:54 ` Heming Zhao
2024-03-13 1:34 ` Heming Zhao
2024-03-13 9:09 ` Joseph Qi
2024-03-13 12:32 ` Heming Zhao [this message]
-- strict thread matches above, loose matches on Subject: below --
2024-03-19 6:57 Heming Zhao
2024-03-19 7:00 ` Heming Zhao
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=c94f3dd8-7cc6-4a0c-9073-0bb92e81e863@suse.com \
--to=heming.zhao@suse.com \
--cc=ailiop@suse.com \
--cc=joseph.qi@linux.alibaba.com \
--cc=ocfs2-devel@lists.linux.dev \
/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 read-only IMAP folder(s) and NNTP newsgroup(s).