From: Peter Xu <peterx@redhat.com>
To: Lorenzo Stoakes <lstoakes@gmail.com>
Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org,
Matthew Wilcox <willy@infradead.org>,
Andrea Arcangeli <aarcange@redhat.com>,
John Hubbard <jhubbard@nvidia.com>,
Mike Rapoport <rppt@kernel.org>,
David Hildenbrand <david@redhat.com>,
Vlastimil Babka <vbabka@suse.cz>,
"Kirill A . Shutemov" <kirill@shutemov.name>,
Andrew Morton <akpm@linux-foundation.org>,
Mike Kravetz <mike.kravetz@oracle.com>,
James Houghton <jthoughton@google.com>,
Hugh Dickins <hughd@google.com>
Subject: Re: [PATCH 5/7] mm/gup: Cleanup next_page handling
Date: Mon, 19 Jun 2023 15:18:13 -0400 [thread overview]
Message-ID: <ZJCp9aBS8INMkehh@x1n> (raw)
In-Reply-To: <5886f78c-3ff8-4b64-9aa6-027c22e7d5fc@lucifer.local>
On Sat, Jun 17, 2023 at 09:00:34PM +0100, Lorenzo Stoakes wrote:
> On Sat, Jun 17, 2023 at 08:48:38PM +0100, Lorenzo Stoakes wrote:
> > On Tue, Jun 13, 2023 at 05:53:44PM -0400, Peter Xu wrote:
> > > The only path that doesn't use generic "**pages" handling is the gate vma.
> > > Make it use the same path, meanwhile tune the next_page label upper to
> > > cover "**pages" handling. This prepares for THP handling for "**pages".
> > >
> > > Signed-off-by: Peter Xu <peterx@redhat.com>
> > > ---
> > > mm/gup.c | 7 +++----
> > > 1 file changed, 3 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/mm/gup.c b/mm/gup.c
> > > index 8d59ae4554e7..a2d1b3c4b104 100644
> > > --- a/mm/gup.c
> > > +++ b/mm/gup.c
> > > @@ -1135,7 +1135,7 @@ static long __get_user_pages(struct mm_struct *mm,
> > > if (!vma && in_gate_area(mm, start)) {
> > > ret = get_gate_page(mm, start & PAGE_MASK,
> > > gup_flags, &vma,
> > > - pages ? &pages[i] : NULL);
> > > + pages ? &page : NULL);
> >
> > Good spot... ugh that we handled this differently.
> >
> > > if (ret)
> > > goto out;
> > > ctx.page_mask = 0;
> >
> > We can drop this line now right? As the new next_page block will duplicate
> > this.
>
> OK I can see why you left this in given the last patch in the series :)
> Please disregard.
Yes the other "page_mask=0" will be removed in the next (not last) patch.
>
> >
> > > @@ -1205,19 +1205,18 @@ static long __get_user_pages(struct mm_struct *mm,
> > > ret = PTR_ERR(page);
> > > goto out;
> > > }
> > > -
> > > - goto next_page;
> >
> > This is neat, we've already checked if pages != NULL so the if (pages)
> > block at the new next_page label will not be run.
Yes.
> >
> > > } else if (IS_ERR(page)) {
> > > ret = PTR_ERR(page);
> > > goto out;
> > > }
> > > +next_page:
> > > if (pages) {
> > > pages[i] = page;
> > > flush_anon_page(vma, page, start);
> > > flush_dcache_page(page);
> >
> > I guess there's no harm that we now flush here, though it seems to me to be
> > superfluous, it's not a big deal I don't think.
I'd say GUP on gate vma page should be so rare so yeah I think it shouldn't
be a big deal. Even iiuc vsyscall=xonly should be the default, so gup may
have already failed on a gate vma page even trying to read-only..
> >
> > > ctx.page_mask = 0;
> > > }
> > > -next_page:
> > > +
> > > page_increm = 1 + (~(start >> PAGE_SHIFT) & ctx.page_mask);
> > > if (page_increm > nr_pages)
> > > page_increm = nr_pages;
> > > --
> > > 2.40.1
> > >
> >
> > Other than that, LGTM,
> >
> > Reviewed-by: Lorenzo Stoakes <lstoakes@gmail.com>
Thanks for looking!
--
Peter Xu
next prev parent reply other threads:[~2023-06-19 19:18 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-13 21:53 [PATCH 0/7] mm/gup: Unify hugetlb, speed up thp Peter Xu
2023-06-13 21:53 ` [PATCH 1/7] mm/hugetlb: Handle FOLL_DUMP well in follow_page_mask() Peter Xu
2023-06-14 23:24 ` Mike Kravetz
2023-06-16 8:08 ` David Hildenbrand
2023-06-13 21:53 ` [PATCH 2/7] mm/hugetlb: Fix hugetlb_follow_page_mask() on permission checks Peter Xu
2023-06-14 15:31 ` David Hildenbrand
2023-06-14 15:46 ` Peter Xu
2023-06-14 15:57 ` David Hildenbrand
2023-06-15 0:11 ` Mike Kravetz
2023-06-13 21:53 ` [PATCH 3/7] mm/hugetlb: Add page_mask for hugetlb_follow_page_mask() Peter Xu
2023-06-15 0:17 ` Mike Kravetz
2023-06-16 8:11 ` David Hildenbrand
2023-06-19 21:43 ` Peter Xu
2023-06-20 7:01 ` David Hildenbrand
2023-06-20 14:40 ` Peter Xu
2023-06-13 21:53 ` [PATCH 4/7] mm/hugetlb: Prepare hugetlb_follow_page_mask() for FOLL_PIN Peter Xu
2023-06-14 14:57 ` David Hildenbrand
2023-06-14 15:11 ` Peter Xu
2023-06-14 15:17 ` David Hildenbrand
2023-06-14 15:31 ` Peter Xu
2023-06-14 15:47 ` David Hildenbrand
2023-06-14 15:51 ` Peter Xu
2023-06-15 0:25 ` Mike Kravetz
2023-06-15 19:42 ` Peter Xu
2023-06-13 21:53 ` [PATCH 5/7] mm/gup: Cleanup next_page handling Peter Xu
2023-06-17 19:48 ` Lorenzo Stoakes
2023-06-17 20:00 ` Lorenzo Stoakes
2023-06-19 19:18 ` Peter Xu [this message]
2023-06-13 21:53 ` [PATCH 6/7] mm/gup: Accelerate thp gup even for "pages != NULL" Peter Xu
2023-06-14 14:58 ` Matthew Wilcox
2023-06-14 15:19 ` Peter Xu
2023-06-14 15:35 ` Peter Xu
2023-06-17 20:27 ` Lorenzo Stoakes
2023-06-19 19:37 ` Peter Xu
2023-06-19 20:24 ` Peter Xu
2023-06-13 21:53 ` [PATCH 7/7] mm/gup: Retire follow_hugetlb_page() Peter Xu
2023-06-14 14:37 ` Jason Gunthorpe
2023-06-17 20:40 ` Lorenzo Stoakes
2023-06-19 19:41 ` Peter Xu
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=ZJCp9aBS8INMkehh@x1n \
--to=peterx@redhat.com \
--cc=aarcange@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=david@redhat.com \
--cc=hughd@google.com \
--cc=jhubbard@nvidia.com \
--cc=jthoughton@google.com \
--cc=kirill@shutemov.name \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lstoakes@gmail.com \
--cc=mike.kravetz@oracle.com \
--cc=rppt@kernel.org \
--cc=vbabka@suse.cz \
--cc=willy@infradead.org \
/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.