From: Qu Wenruo <wqu@suse.com>
To: Filipe Manana <fdmanana@kernel.org>
Cc: linux-btrfs@vger.kernel.org
Subject: Re: [PATCH 1/3] btrfs: remove unnecessary early exits in delalloc folio lock and unlock
Date: Sat, 5 Apr 2025 08:14:20 +1030 [thread overview]
Message-ID: <dc2618d9-0ff8-40f1-b5e7-93644fbbe17c@suse.com> (raw)
In-Reply-To: <CAL3q7H5vSyG3zpCZ5hbPT8aR2-xODazLwcKhWGhJYUUMLTus1w@mail.gmail.com>
在 2025/4/5 02:34, Filipe Manana 写道:
> On Fri, Apr 4, 2025 at 2:48 AM Qu Wenruo <wqu@suse.com> wrote:
>>
>> Inside function unlock_delalloc_folio() and lock_delalloc_folios(), we
>
> function -> functions
>
>> have the following early exist:
>
> exist -> exit
>
>>
>> if (index == locked_folio->index && end_index == index)
>> return;
>>
>> This allows us to exist early if the range are inside the same locked
>
> exist -> exit
> the range are inside -> the range is inside
>
>> folio.
>>
>> But even without the above early check, the existing code can handle it
>> well, as both __process_folios_contig() and lock_delalloc_folios() will
>> skip any folio page lock/unlock if it's on the locked folio.
>>
>> Just remove those unnecessary early exits.
>
> It looks good to me from a functional point of view.
>
> But without this early exits there's a bit of work done, from function
> calls to initializing and releasing folio batches, calling
> filemap_get_folios_contig() which
> will search the mapping's xarray and always grab one folio and add it
> to the batch, etc.
>
> It's not uncommon to do IO on a range not spanning more than one
> folio, especially when supporting large folios, which will be more
> likely.
> I understand the goal here is to remove some code, but this code is
> cheaper compared to all that unnecessary overhead.
>
> Have you considered that?
Yes, but the main reason here is the usage of (folio->index == index) check.
With large folios, such check is no longer reliable anyway, and
initially I thought to just change it to folio_contains(), but it turns
out that is not really needed either.
So that's the main reason to get rid this of these early exits.
Thanks,
Qu
>
> Thanks.
>
>>
>> Signed-off-by: Qu Wenruo <wqu@suse.com>
>> ---
>> fs/btrfs/extent_io.c | 8 --------
>> 1 file changed, 8 deletions(-)
>>
>> diff --git a/fs/btrfs/extent_io.c b/fs/btrfs/extent_io.c
>> index 8b29eeac3884..013268f70621 100644
>> --- a/fs/btrfs/extent_io.c
>> +++ b/fs/btrfs/extent_io.c
>> @@ -224,12 +224,7 @@ static noinline void unlock_delalloc_folio(const struct inode *inode,
>> const struct folio *locked_folio,
>> u64 start, u64 end)
>> {
>> - unsigned long index = start >> PAGE_SHIFT;
>> - unsigned long end_index = end >> PAGE_SHIFT;
>> -
>> ASSERT(locked_folio);
>> - if (index == locked_folio->index && end_index == index)
>> - return;
>>
>> __process_folios_contig(inode->i_mapping, locked_folio, start, end,
>> PAGE_UNLOCK);
>> @@ -246,9 +241,6 @@ static noinline int lock_delalloc_folios(struct inode *inode,
>> u64 processed_end = start;
>> struct folio_batch fbatch;
>>
>> - if (index == locked_folio->index && index == end_index)
>> - return 0;
>> -
>> folio_batch_init(&fbatch);
>> while (index <= end_index) {
>> unsigned int found_folios, i;
>> --
>> 2.49.0
>>
>>
next prev parent reply other threads:[~2025-04-04 21:44 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-04 1:47 [PATCH 0/3] btrfs: fsstress hang fix for large data folios Qu Wenruo
2025-04-04 1:47 ` [PATCH 1/3] btrfs: remove unnecessary early exits in delalloc folio lock and unlock Qu Wenruo
2025-04-04 16:04 ` Filipe Manana
2025-04-04 21:44 ` Qu Wenruo [this message]
2025-04-05 17:54 ` Filipe Manana
2025-04-04 1:47 ` [PATCH 2/3] btrfs: use folio_contains() for EOF detection Qu Wenruo
2025-04-04 16:09 ` Filipe Manana
2025-04-07 18:39 ` David Sterba
2025-04-07 21:58 ` Qu Wenruo
2025-04-08 23:12 ` David Sterba
2025-04-08 23:16 ` Qu Wenruo
2025-04-04 1:47 ` [PATCH 3/3] btrfs: get rid of filemap_get_folios_contig() calls Qu Wenruo
2025-04-04 16:38 ` Filipe Manana
2025-04-04 21:51 ` Qu Wenruo
2025-04-04 22:00 ` Qu Wenruo
2025-04-22 22:47 ` Qu Wenruo
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=dc2618d9-0ff8-40f1-b5e7-93644fbbe17c@suse.com \
--to=wqu@suse.com \
--cc=fdmanana@kernel.org \
--cc=linux-btrfs@vger.kernel.org \
/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