Linux-mm Archive mirror
 help / color / mirror / Atom feed
From: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
To: Christoph Hellwig <hch@infradead.org>,
	"Pankaj Raghav (Samsung)" <kernel@pankajraghav.com>
Cc: 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, 08 May 2024 00:08:56 +0530	[thread overview]
Message-ID: <87edado4an.fsf@gmail.com> (raw)

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?

> lower level interfaces like get_huge_zero_page and use them at
> mount time.
>

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

maybe something like if len > 16 * pagesize?

>> +		if (!folio)
>> +			folio = zero_page_folio;
>
> And then don't bother with a fallback.

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?

-ritesh


             reply	other threads:[~2024-05-07 18:39 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-05-07 18:38 Ritesh Harjani [this message]
2024-05-08 11:42 ` [RFC] iomap: use huge zero folio in iomap_dio_zero Christoph Hellwig
  -- 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=87edado4an.fsf@gmail.com \
    --to=ritesh.list@gmail.com \
    --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@infradead.org \
    --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=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).