From: "Sooyong Suk" <s.suk@samsung.com>
To: "'Suren Baghdasaryan'" <surenb@google.com>
Cc: "'Jaewon Kim'" <jaewon31.kim@gmail.com>,
"'Christoph Hellwig'" <hch@infradead.org>,
<viro@zeniv.linux.org.uk>, <linux-kernel@vger.kernel.org>,
<akpm@linux-foundation.org>, <linux-mm@kvack.org>,
<spssyr@gmail.com>, <axboe@kernel.dk>,
<linux-block@vger.kernel.org>, <dhavale@google.com>
Subject: RE: [RFC PATCH] block, fs: use FOLL_LONGTERM as gup_flags for direct IO
Date: Fri, 7 Mar 2025 15:38:37 +0900 [thread overview]
Message-ID: <014b01db8f2b$8ed1c740$ac7555c0$@samsung.com> (raw)
In-Reply-To: <CAJuCfpHjV=nRmkAGrf-tyCxEEygZ0CuW-PRp+F_vHwFbfYS8dA@mail.gmail.com>
> On Thu, Mar 6, 2025 at 6:07 PM Sooyong Suk <s.suk@samsung.com> wrote:
> >
> > > On Fri, Mar 7, 2025 at 12:26 AM Christoph Hellwig
> > > <hch@infradead.org>
> > > wrote:
> > > >
> > > > On Thu, Mar 06, 2025 at 04:40:56PM +0900, Sooyong Suk wrote:
> > > > > There are GUP references to pages that are serving as direct IO
> > > buffers.
> > > > > Those pages can be allocated from CMA pageblocks despite they
> > > > > can be pinned until the DIO is completed.
> > > >
> > > > direct I/O is eactly the case that is not FOLL_LONGTERM and one of
> > > > the reasons to even have the flag. So big fat no to this.
> > > >
> > >
> >
> > Understood.
> >
> > > Hello, thank you for your comment.
> > > We, Sooyong and I, wanted to get some opinions about this
> > > FOLL_LONGTERM for direct I/O as CMA memory got pinned pages which
> > > had been pinned from direct io.
> > >
> > > > You also completely failed to address the relevant mailinglist and
> > > > maintainers.
> > >
> > > I added block maintainer Jens Axboe and the block layer maillinst
> > > here, and added Suren and Sandeep, too.
>
> I'm very far from being a block layer expert :)
>
> >
> > Then, what do you think of using PF_MEMALLOC_PIN for this context as
> below?
> > This will only remove __GFP_MOVABLE from its allocation flag.
> > Since __bio_iov_iter_get_pages() indicates that it will pin user or
> > kernel pages, there seems to be no reason not to use this process flag.
>
> I think this will help you only when the pages are faulted in but if
> __get_user_pages() finds an already mapped page which happens to be
> allocated from CMA, it will not migrate it. So, you might still end up
> with unmovable pages inside CMA.
>
Yes, you're right.
However, we can at least prevent issues from fault-in cases and mitigate
the overall probability of CMA allocation failure. And the pinned pages that
we observed from snapuserd was also allocated by fault-in.
> >
> > block/bio.c | 3 +++
> > 1 file changed, 3 insertions(+)
> >
> > diff --git a/block/bio.c b/block/bio.c index 65c796ecb..671e28966
> > 100644
> > --- a/block/bio.c
> > +++ b/block/bio.c
> > @@ -1248,6 +1248,7 @@ static int __bio_iov_iter_get_pages(struct bio
> *bio, struct iov_iter *iter)
> > unsigned len, i = 0;
> > size_t offset;
> > int ret = 0;
> > + unsigned int flags;
> >
> > /*
> > * Move page array up in the allocated memory for the bio vecs
> > as far as @@ -1267,9 +1268,11 @@ static int
> __bio_iov_iter_get_pages(struct bio *bio, struct iov_iter *iter)
> > * result to ensure the bio's total size is correct. The remainder
> of
> > * the iov data will be picked up in the next bio iteration.
> > */
> > + flags = memalloc_pin_save();
> > size = iov_iter_extract_pages(iter, &pages,
> > UINT_MAX - bio->bi_iter.bi_size,
> > nr_pages, extraction_flags,
> > &offset);
> > + memalloc_pin_restore(flags);
> > if (unlikely(size <= 0))
> > return size ? size : -EFAULT;
> >
> >
next prev parent reply other threads:[~2025-03-07 6:38 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CGME20250306074101epcas1p4b24ac546f93df2c7fe3176607b20e47f@epcas1p4.samsung.com>
2025-03-06 7:40 ` [RFC PATCH] block, fs: use FOLL_LONGTERM as gup_flags for direct IO Sooyong Suk
2025-03-06 15:26 ` Christoph Hellwig
2025-03-06 23:28 ` Jaewon Kim
2025-03-07 2:07 ` Sooyong Suk
2025-03-07 2:28 ` Suren Baghdasaryan
2025-03-07 6:38 ` Sooyong Suk [this message]
2025-03-12 15:17 ` Christoph Hellwig
2025-03-12 15:20 ` Suren Baghdasaryan
2025-03-12 15:25 ` Christoph Hellwig
2025-03-12 15:38 ` Suren Baghdasaryan
2025-03-12 15:52 ` Christoph Hellwig
2025-03-12 16:03 ` Bart Van Assche
2025-03-12 16:06 ` Suren Baghdasaryan
2025-03-12 16:21 ` Christoph Hellwig
2025-03-07 20:23 ` Matthew Wilcox
2025-03-07 21:37 ` Suren Baghdasaryan
2025-03-12 15:21 ` Christoph Hellwig
2025-03-13 22:49 ` David Hildenbrand
2025-03-15 1:04 ` John Hubbard
2025-03-15 23:00 ` David Hildenbrand
2025-03-15 23:09 ` Zi Yan
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='014b01db8f2b$8ed1c740$ac7555c0$@samsung.com' \
--to=s.suk@samsung.com \
--cc=akpm@linux-foundation.org \
--cc=axboe@kernel.dk \
--cc=dhavale@google.com \
--cc=hch@infradead.org \
--cc=jaewon31.kim@gmail.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=spssyr@gmail.com \
--cc=surenb@google.com \
--cc=viro@zeniv.linux.org.uk \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.