From: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
To: Matthew Wilcox <willy@infradead.org>
Cc: linux-ext4@vger.kernel.org, Jan Kara <jack@suse.cz>,
Ojaswin Mujoo <ojaswin@linux.ibm.com>,
Disha Goel <disgoel@linux.ibm.com>
Subject: Re: [RFCv1 3/4] ext4: Make mpage_journal_page_buffers use folio
Date: Mon, 17 Apr 2023 10:46:24 +0530 [thread overview]
Message-ID: <87ttxfhyvr.fsf@doe.com> (raw)
In-Reply-To: <87zg77ici3.fsf@doe.com>
Ritesh Harjani (IBM) <ritesh.list@gmail.com> writes:
> Matthew Wilcox <willy@infradead.org> writes:
>
>> On Mon, Apr 17, 2023 at 12:01:52AM +0530, Ritesh Harjani (IBM) wrote:
>>> This patch converts mpage_journal_page_buffers() to use folio and also
>>> removes the PAGE_SIZE assumption.
>>
>> Bit of an oversight on my part. I neglected to do this after Jan added
>> it. Perils of parallel development ...
>>
>
> Yes, these got left overs because of the parallel series.
>
>>> -static int ext4_journal_page_buffers(handle_t *handle, struct page *page,
>>> - int len)
>>> +static int ext4_journal_page_buffers(handle_t *handle, struct folio *folio,
>>> + size_t len)
>>
>> Should this be called ext4_journal_folio_buffers?
>
> Sure. Will make the change. Otherwise this patch looks good to you?
> I also had a query regarding setting "len = size - folio_pos(folio)" in this patch.
> Details of which I had pasted in the cover letter. Let me copy-paste
> it here from the cover letter. Could you please take a look at it?
>
>
> <copy-paste>
> Also had a query w.r.t your change [1]. I couldn't understand this change diff
> from [1]. Given if we are making the conversion to folio, then shouldn't we do
> len = size - folio_pos(pos), instead of len = size & ~PAGE_MASK
> Could you please tell if the current change in [1] is kept deliberately?
> At other places you did make len as size - folio_pos(pos) which removes the
> PAGE_SIZE assumption.
>
> -static int mpage_submit_page(struct mpage_da_data *mpd, struct page *page)
> +static int mpage_submit_folio(struct mpage_da_data *mpd, struct folio *folio)
> {
> - int len;
> + size_t len;
>
> <...>
>
> size = i_size_read(mpd->inode);
> - if (page->index == size >> PAGE_SHIFT &&
> + len = folio_size(folio);
> + if (folio_pos(folio) + len > size &&
> !ext4_verity_in_progress(mpd->inode))
> len = size & ~PAGE_MASK;
> - else
> - len = PAGE_SIZE;
> - err = ext4_bio_write_page(&mpd->io_submit, page, len);
> + err = ext4_bio_write_page(&mpd->io_submit, &folio->page, len);
> if (!err)
> mpd->wbc->nr_to_write--;
>
> [1]: https://lore.kernel.org/linux-ext4/20230324180129.1220691-7-willy@infradead.org/
Here is the complete function. Looking at it again, I think we should make
len = size - folio_pos(folio) (at linenumber 26, like how it is done at
other places in ext4-folio patches), because we now call
ext4_bio_write_folio() instead of ext4_bio_write_page().
Although I know it doesn't make a difference in the functionality today
since folio_size(folio) today in case of ext4 is still PAGE_SIZE.
Please let me know if this understanding is correct. If yes, then I can
write a patch to make len = size - folio_pos(folio) at line 26.
If not I will be happy to know more about what am I missing.
1 static int mpage_submit_folio(struct mpage_da_data *mpd, struct folio *folio)
2 {
3 size_t len;
4 loff_t size;
5 int err;
6
7 BUG_ON(folio->index != mpd->first_page);
8 folio_clear_dirty_for_io(folio);
9 /*
10 * We have to be very careful here! Nothing protects writeback path
11 * against i_size changes and the page can be writeably mapped into
12 * page tables. So an application can be growing i_size and writing
13 * data through mmap while writeback runs. folio_clear_dirty_for_io()
14 * write-protects our page in page tables and the page cannot get
15 * written to again until we release folio lock. So only after
16 * folio_clear_dirty_for_io() we are safe to sample i_size for
17 * ext4_bio_write_folio() to zero-out tail of the written page. We rely
18 * on the barrier provided by folio_test_clear_dirty() in
19 * folio_clear_dirty_for_io() to make sure i_size is really sampled only
20 * after page tables are updated.
21 */
22 size = i_size_read(mpd->inode);
23 len = folio_size(folio);
24 if (folio_pos(folio) + len > size &&
25 !ext4_verity_in_progress(mpd->inode))
26 len = size & ~PAGE_MASK;
27 err = ext4_bio_write_folio(&mpd->io_submit, folio, len);
28 if (!err)
29 mpd->wbc->nr_to_write--;
30
31 return err;
32 }
Thanks a lot!!
-ritesh
next prev parent reply other threads:[~2023-04-17 5:16 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-16 18:31 [RFCv1 0/4] ext4: misc left over folio changes Ritesh Harjani (IBM)
2023-04-16 18:31 ` [RFCv1 1/4] ext4: kill unused function ext4_journalled_write_inline_data Ritesh Harjani (IBM)
2023-04-16 19:32 ` Matthew Wilcox
2023-04-16 18:31 ` [RFCv1 2/4] ext4: Change remaining tracepoints to use folio Ritesh Harjani (IBM)
2023-04-16 19:39 ` Matthew Wilcox
2023-04-16 18:31 ` [RFCv1 3/4] ext4: Make mpage_journal_page_buffers " Ritesh Harjani (IBM)
2023-04-16 19:46 ` Matthew Wilcox
2023-04-17 0:22 ` Ritesh Harjani
2023-04-17 5:16 ` Ritesh Harjani [this message]
2023-04-16 18:31 ` [RFCv1 4/4] ext4: Make ext4_write_inline_data_end() " Ritesh Harjani (IBM)
2023-04-16 19:58 ` Matthew Wilcox
2023-05-13 21:55 ` [RFCv1 0/4] ext4: misc left over folio changes Theodore Ts'o
2023-05-14 4:22 ` Ritesh Harjani
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=87ttxfhyvr.fsf@doe.com \
--to=ritesh.list@gmail.com \
--cc=disgoel@linux.ibm.com \
--cc=jack@suse.cz \
--cc=linux-ext4@vger.kernel.org \
--cc=ojaswin@linux.ibm.com \
--cc=willy@infradead.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;
as well as URLs for NNTP newsgroup(s).