From: Christoph Hellwig <hch@infradead.org>
To: Ritesh Harjani <ritesh.list@gmail.com>
Cc: Christoph Hellwig <hch@infradead.org>,
"Pankaj Raghav (Samsung)" <kernel@pankajraghav.com>,
hch@lst.de, willy@infradead.org, mcgrof@kernel.org,
akpm@linux-foundation.org, brauner@kernel.org,
chandan.babu@oracle.com, david@fromorbit.com, djwong@kernel.org,
gost.dev@samsung.com, hare@suse.de, john.g.garry@oracle.com,
linux-block@vger.kernel.org, linux-fsdevel@vger.kernel.org,
linux-mm@kvack.org, linux-xfs@vger.kernel.org,
p.raghav@samsung.com, ziy@nvidia.com
Subject: Re: [RFC] iomap: use huge zero folio in iomap_dio_zero
Date: Wed, 8 May 2024 04:42:36 -0700 [thread overview]
Message-ID: <ZjtlLH-y5eBE9W9g@infradead.org> (raw)
In-Reply-To: <87edado4an.fsf@gmail.com>
On Wed, May 08, 2024 at 12:08:56AM +0530, Ritesh Harjani wrote:
> Christoph Hellwig <hch@infradead.org> writes:
>
> > On Tue, May 07, 2024 at 04:58:12PM +0200, Pankaj Raghav (Samsung) wrote:
> >> + if (len > PAGE_SIZE) {
> >> + folio = mm_get_huge_zero_folio(current->mm);
> >
> > I don't think the mm_struct based interfaces work well here, as I/O
> > completions don't come in through the same mm. You'll want to use
>
> But right now iomap_dio_zero() is only called from the submission
> context right i.e. iomap_dio_bio_iter(). Could you please explain the
> dependency with the completion context to have same mm_struct here?
mm_get_huge_zero_folio ties the huge folio reference to the mm_struct.
So when the process that kicked this off exists you lose the reference to
it. Which doesn't make sense, we need it as long as the file system
is mounted.
> Even so, should we not check whether allocation of hugepage is of any
> value or not depending upon how large the length or (blocksize in case of
> mount time) really is.
> i.e. say if the len for zeroing is just 2 times the PAGE_SIZE, then it
> doesn't really make sense to allocate a 2MB hugepage and sometimes 16MB
> hugepage on some archs (like Power with hash mmu).
I'd kinda expect we'll just need it for so many other reasons that I
wouldn't worry.
> The hugepage allocation can still fail during mount time (if we mount
> late when the system memory is already fragmented). So we might still
> need a fallback to ZERO_PAGE(0), right?
Memory fragmentation should not prevent the allocation due to
compaction. And if we're really badly out of memory 2MB isn't going
to make the difference vs all the other memory used by an XFS file
system.
next prev parent reply other threads:[~2024-05-08 11:42 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-07 18:38 [RFC] iomap: use huge zero folio in iomap_dio_zero Ritesh Harjani
2024-05-08 11:42 ` Christoph Hellwig [this message]
-- strict thread matches above, loose matches on Subject: below --
2024-05-03 9:53 [PATCH v5 07/11] iomap: fix iomap_dio_zero() for fs bs > system page size Luis Chamberlain
2024-05-07 14:58 ` [RFC] iomap: use huge zero folio in iomap_dio_zero Pankaj Raghav (Samsung)
2024-05-07 15:11 ` Zi Yan
2024-05-07 16:11 ` Christoph Hellwig
2024-05-08 11:39 ` Pankaj Raghav (Samsung)
2024-05-08 11:43 ` Christoph Hellwig
2024-05-09 12:31 ` Pankaj Raghav (Samsung)
2024-05-09 12:46 ` Christoph Hellwig
2024-05-09 12:55 ` Pankaj Raghav (Samsung)
2024-05-09 12:58 ` Christoph Hellwig
2024-05-09 14:32 ` Darrick J. Wong
2024-05-09 15:05 ` Christoph Hellwig
2024-05-09 15:08 ` Darrick J. Wong
2024-05-09 15:09 ` Christoph Hellwig
2024-05-15 0:50 ` Matthew Wilcox
2024-05-15 2:34 ` Keith Busch
2024-05-15 4:04 ` Matthew Wilcox
2024-05-15 15:59 ` Pankaj Raghav (Samsung)
2024-05-15 18:03 ` Matthew Wilcox
2024-05-16 15:02 ` Pankaj Raghav (Samsung)
2024-05-17 12:36 ` Hannes Reinecke
2024-05-17 12:56 ` Hannes Reinecke
2024-05-17 13:30 ` Matthew Wilcox
2024-05-15 11:48 ` Christoph Hellwig
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=ZjtlLH-y5eBE9W9g@infradead.org \
--to=hch@infradead.org \
--cc=akpm@linux-foundation.org \
--cc=brauner@kernel.org \
--cc=chandan.babu@oracle.com \
--cc=david@fromorbit.com \
--cc=djwong@kernel.org \
--cc=gost.dev@samsung.com \
--cc=hare@suse.de \
--cc=hch@lst.de \
--cc=john.g.garry@oracle.com \
--cc=kernel@pankajraghav.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-xfs@vger.kernel.org \
--cc=mcgrof@kernel.org \
--cc=p.raghav@samsung.com \
--cc=ritesh.list@gmail.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 read-only IMAP folder(s) and NNTP newsgroup(s).