From: "Pankaj Raghav (Samsung)" <kernel@pankajraghav.com>
To: Matthew Wilcox <willy@infradead.org>
Cc: linux-xfs@vger.kernel.org, linux-fsdevel@vger.kernel.org,
linux-kernel@vger.kernel.org, david@fromorbit.com,
chandan.babu@oracle.com, akpm@linux-foundation.org,
mcgrof@kernel.org, ziy@nvidia.com, hare@suse.de,
djwong@kernel.org, gost.dev@samsung.com, linux-mm@kvack.org,
Pankaj Raghav <p.raghav@samsung.com>
Subject: Re: [PATCH 10/13] iomap: fix iomap_dio_zero() for fs bs > system page size
Date: Tue, 27 Feb 2024 10:33:21 +0100 [thread overview]
Message-ID: <3pqmgrlewo6ctcwakdvbvjqixac5en6irlipe5aiz6vkylfyni@2luhrs36ke5r> (raw)
In-Reply-To: <ZdzRU0sMqFYlNC01@casper.infradead.org>
> I thought we were going to use the huge_zero_page for this?
Yes. We discussed that huge_zero_page might fail, so we concluded that
we needed an api that can return arbitrary folio order that will not
fail:
```
your point about it possibly failing is correct. so i think we need an
api which definitely returns a folio, but it might be of arbitrary
order.
```
I couldn't come up with implementing your latter suggestion, so I
informed darrick that let's use this patch for now, and add the
arbitrary folio order with zero as a later enhancement.
If we want to use mm_huge_zero_page, then this should work:
diff --git a/fs/iomap/direct-io.c b/fs/iomap/direct-io.c
index 04f6c5548136..b6a3f52f48da 100644
--- a/fs/iomap/direct-io.c
+++ b/fs/iomap/direct-io.c
@@ -237,10 +237,17 @@ static void iomap_dio_zero(const struct iomap_iter *iter, struct iomap_dio *dio,
{
struct inode *inode = file_inode(dio->iocb->ki_filp);
struct page *page = ZERO_PAGE(0);
+ struct folio *folio = NULL;
struct bio *bio;
WARN_ON_ONCE(len > (BIO_MAX_VECS * PAGE_SIZE));
+ if (len > PAGE_SIZE) {
+ page = mm_get_huge_zero_page(current->mm);
+ if (!page)
+ page = ZERO_PAGE(0);
+ }
+
bio = iomap_dio_alloc_bio(iter, dio, BIO_MAX_VECS,
REQ_OP_WRITE | REQ_SYNC | REQ_IDLE);
fscrypt_set_bio_crypt_ctx(bio, inode, pos >> inode->i_blkbits,
@@ -249,13 +256,15 @@ static void iomap_dio_zero(const struct iomap_iter *iter, struct iomap_dio *dio,
bio->bi_iter.bi_sector = iomap_sector(&iter->iomap, pos);
bio->bi_private = dio;
bio->bi_end_io = iomap_dio_bio_end_io;
+ folio = page_folio(page);
while (len) {
- unsigned int io_len = min_t(unsigned int, len, PAGE_SIZE);
+ size_t size = min(len, folio_size(folio));
- __bio_add_page(bio, page, io_len, 0);
- len -= io_len;
+ bio_add_folio_nofail(bio, folio, size, 0);
+ len -= size;
}
+
iomap_dio_submit_bio(iter, dio, bio, pos);
}
Let me know if we should go for this or let's keep the original patch
and add a ZERO_FOLIO_ORDER API that will not fail and use it as a later
enhancement.
next prev parent reply other threads:[~2024-02-27 9:33 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-26 9:49 [PATCH 00/13] enable bs > ps in XFS Pankaj Raghav (Samsung)
2024-02-26 9:49 ` [PATCH 01/13] mm: Support order-1 folios in the page cache Pankaj Raghav (Samsung)
2024-02-26 9:49 ` [PATCH 02/13] fs: Allow fine-grained control of folio sizes Pankaj Raghav (Samsung)
2024-02-26 9:49 ` [PATCH 03/13] filemap: align the index to mapping_min_order in the page cache Pankaj Raghav (Samsung)
2024-02-26 14:40 ` Matthew Wilcox
2024-02-27 10:06 ` Pankaj Raghav (Samsung)
2024-02-27 16:22 ` Kent Overstreet
2024-02-27 16:36 ` Pankaj Raghav (Samsung)
2024-02-27 16:40 ` Kent Overstreet
2024-02-27 16:55 ` Pankaj Raghav (Samsung)
2024-02-27 17:02 ` Kent Overstreet
2024-02-27 17:09 ` Pankaj Raghav (Samsung)
2024-02-26 9:49 ` [PATCH 04/13] filemap: use mapping_min_order while allocating folios Pankaj Raghav (Samsung)
2024-02-26 14:47 ` Matthew Wilcox
2024-02-27 12:09 ` Pankaj Raghav (Samsung)
2024-02-26 9:49 ` [PATCH 05/13] readahead: set file_ra_state->ra_pages to be at least mapping_min_order Pankaj Raghav (Samsung)
2024-02-26 14:49 ` Matthew Wilcox
2024-02-27 12:42 ` Pankaj Raghav (Samsung)
2024-02-26 9:49 ` [PATCH 06/13] readahead: align index to mapping_min_order in ondemand_ra and force_ra Pankaj Raghav (Samsung)
2024-02-26 9:49 ` [PATCH 07/13] readahead: rework loop in page_cache_ra_unbounded() Pankaj Raghav (Samsung)
2024-02-26 9:49 ` [PATCH 08/13] readahead: allocate folios with mapping_min_order in ra_(unbounded|order) Pankaj Raghav (Samsung)
2024-02-26 9:49 ` [PATCH 09/13] mm: do not split a folio if it has minimum folio order requirement Pankaj Raghav (Samsung)
2024-02-26 9:49 ` [PATCH 10/13] iomap: fix iomap_dio_zero() for fs bs > system page size Pankaj Raghav (Samsung)
2024-02-26 17:58 ` Matthew Wilcox
2024-02-27 9:33 ` Pankaj Raghav (Samsung) [this message]
2024-02-26 9:49 ` [PATCH 11/13] xfs: expose block size in stat Pankaj Raghav (Samsung)
2024-02-26 12:44 ` Dave Chinner
2024-02-27 8:53 ` Pankaj Raghav (Samsung)
2024-02-26 9:49 ` [PATCH 12/13] xfs: make the calculation generic in xfs_sb_validate_fsb_count() Pankaj Raghav (Samsung)
2024-02-26 12:47 ` Dave Chinner
2024-02-26 13:21 ` Matthew Wilcox
2024-02-27 8:44 ` Pankaj Raghav (Samsung)
2024-02-26 9:49 ` [PATCH 13/13] xfs: enable block size larger than page size support Pankaj Raghav (Samsung)
2024-02-26 13:26 ` Matthew Wilcox
2024-02-26 21:18 ` Dave Chinner
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=3pqmgrlewo6ctcwakdvbvjqixac5en6irlipe5aiz6vkylfyni@2luhrs36ke5r \
--to=kernel@pankajraghav.com \
--cc=akpm@linux-foundation.org \
--cc=chandan.babu@oracle.com \
--cc=david@fromorbit.com \
--cc=djwong@kernel.org \
--cc=gost.dev@samsung.com \
--cc=hare@suse.de \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-xfs@vger.kernel.org \
--cc=mcgrof@kernel.org \
--cc=p.raghav@samsung.com \
--cc=willy@infradead.org \
--cc=ziy@nvidia.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;
as well as URLs for NNTP newsgroup(s).