linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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.

  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).