From: Qu Wenruo <quwenruo.btrfs@gmx.com>
To: Naohiro Aota <Naohiro.Aota@wdc.com>, Qu Wenruo <wqu@suse.com>
Cc: "linux-btrfs@vger.kernel.org" <linux-btrfs@vger.kernel.org>,
Johannes Thumshirn <Johannes.Thumshirn@wdc.com>,
"josef@toxicpanda.com" <josef@toxicpanda.com>
Subject: Re: [PATCH v5 3/5] btrfs: lock subpage ranges in one go for writepage_delalloc()
Date: Wed, 22 May 2024 07:46:46 +0930 [thread overview]
Message-ID: <2b26245e-7602-4a00-b79a-eac481708ab3@gmx.com> (raw)
In-Reply-To: <tdxf76yhloruo4pubudlhr2p4xf4spvmhrfsf56jfzxh544id3@fcaaplcp6vwp>
在 2024/5/21 21:24, Naohiro Aota 写道:
> On Tue, May 21, 2024 at 06:15:32PM GMT, Qu Wenruo wrote:
>>
>>
>> 在 2024/5/21 17:41, Naohiro Aota 写道:
>> [...]
>>> Same here.
>>>
>>>> while (delalloc_start < page_end) {
>>>> delalloc_end = page_end;
>>>> if (!find_lock_delalloc_range(&inode->vfs_inode, page,
>>>> @@ -1240,15 +1249,68 @@ static noinline_for_stack int writepage_delalloc(struct btrfs_inode *inode,
>>>> delalloc_start = delalloc_end + 1;
>>>> continue;
>>>> }
>>>> -
>>>> - ret = btrfs_run_delalloc_range(inode, page, delalloc_start,
>>>> - delalloc_end, wbc);
>>>> - if (ret < 0)
>>>> - return ret;
>>>> -
>>>> + btrfs_folio_set_writer_lock(fs_info, folio, delalloc_start,
>>>> + min(delalloc_end, page_end) + 1 -
>>>> + delalloc_start);
>>>> + last_delalloc_end = delalloc_end;
>>>> delalloc_start = delalloc_end + 1;
>>>> }
>>>
>>> Can we bail out on the "if (!last_delalloc_end)" case? It would make the
>>> following code simpler.
>>
>> Mind to explain it a little more?
>>
>> Did you mean something like this:
>>
>> while (delalloc_start < page_end) {
>> /* lock all subpage delalloc range code */
>> }
>> if (!last_delalloc_end)
>> goto finish;
>> while (delalloc_start < page_end) {
>> /* run the delalloc ranges code* /
>> }
>>
>> If so, I can definitely go that way.
>
> Yes, I meant that way. Apparently, "!last_delalloc_end" means it get no
> delalloc region. So, we can just return 0 in that case without touching
> "wbc->nr_to_write" as the current code does.
>
> BTW, is this actually an overlooked error case? Is it OK to progress in
> __extent_writepage() even if we don't run run_delalloc_range() ?
That's totally expected, and it would even be more common in fact.
Consider a very ordinary case like this:
0 4K 8K 12K
|/////////////|///////////////|/////////////|
When running extent_writepage() for page 0, we run delalloc range for
the whole [0, 12K) range, and created an OE for it.
Then __extent_writepage_io() add page range [0, 4k) for bio.
Then extent_writepage() for page 4K, find_lock_delalloc() would not find
any range, as previous iteration at page 0 has already created OE for
the whole [0, 12K) range.
Although we would still run __extent_writepage_io() to add page range
[4k, 8K) to the bio.
The same for page 8K.
Thanks,
Qu
next prev parent reply other threads:[~2024-05-21 22:16 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-18 5:07 [PATCH v5 0/5] btrfs: subpage + zoned fixes Qu Wenruo
2024-05-18 5:07 ` [PATCH v5 1/5] btrfs: make __extent_writepage_io() to write specified range only Qu Wenruo
2024-05-21 7:23 ` Naohiro Aota
2024-05-18 5:07 ` [PATCH v5 2/5] btrfs: subpage: introduce helpers to handle subpage delalloc locking Qu Wenruo
2024-05-21 7:50 ` Naohiro Aota
2024-05-21 7:57 ` Qu Wenruo
2024-05-18 5:07 ` [PATCH v5 3/5] btrfs: lock subpage ranges in one go for writepage_delalloc() Qu Wenruo
2024-05-21 8:11 ` Naohiro Aota
2024-05-21 8:45 ` Qu Wenruo
2024-05-21 11:54 ` Naohiro Aota
2024-05-21 22:16 ` Qu Wenruo [this message]
2024-05-22 1:10 ` Naohiro Aota
2024-05-18 5:07 ` [PATCH v5 4/5] btrfs: do not clear page dirty inside extent_write_locked_range() Qu Wenruo
2024-05-18 5:07 ` [PATCH v5 5/5] btrfs: make extent_write_locked_range() to handle subpage writeback correctly Qu Wenruo
2024-05-21 7:13 ` Naohiro Aota
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=2b26245e-7602-4a00-b79a-eac481708ab3@gmx.com \
--to=quwenruo.btrfs@gmx.com \
--cc=Johannes.Thumshirn@wdc.com \
--cc=Naohiro.Aota@wdc.com \
--cc=josef@toxicpanda.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=wqu@suse.com \
/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