From: Jason Gunthorpe <jgg@nvidia.com>
To: David Hildenbrand <david@redhat.com>
Cc: Alistair Popple <apopple@nvidia.com>,
John Hubbard <jhubbard@nvidia.com>,
linux-mm@kvack.org
Subject: Re: [PATCH 6/8] mm/gup: make locked never NULL in the internal GUP functions
Date: Mon, 23 Jan 2023 14:07:37 -0400 [thread overview]
Message-ID: <Y87M6eFsOdW1pLwy@nvidia.com> (raw)
In-Reply-To: <3e431c82-189a-f82c-6545-b8bd441cce52@redhat.com>
On Mon, Jan 23, 2023 at 01:59:55PM +0100, David Hildenbrand wrote:
> On 23.01.23 13:44, Jason Gunthorpe wrote:
> > On Mon, Jan 23, 2023 at 12:35:28PM +0100, David Hildenbrand wrote:
> > > On 17.01.23 16:58, Jason Gunthorpe wrote:
> > > > Now that NULL locked doesn't have a special meaning we can just make it
> > > > non-NULL in all cases and remove the special tests.
> > > >
> > > > get_user_pages() and pin_user_pages() can safely pass in a locked = 1
> > > >
> > > > get_user_pages_remote) and pin_user_pages_remote() can swap in a local
> > > > variable for locked if NULL is passed.
> > > >
> > > > Remove all the NULL checks.
> > > >
> > > > Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
> > > > ---
> > > > mm/gup.c | 30 ++++++++++++++++++++----------
> > > > 1 file changed, 20 insertions(+), 10 deletions(-)
> > >
> > > ... doesn't really look like a real cleanup. Especially with the
> > >
> > > 2 files changed, 20 insertions(+), 12 deletions(-)
> > >
> > > on the previous patch and a new internal flag ....
> > >
> > > What's the benefit?
> >
> > There are all kinds of unnecessary branches on the faster paths,
> > inside loops, etc to check for NULL when all we really needed was a
> > single bit flag.
>
> ... call me skeptical that this optimization matters in practice ;)
Oh no doubt, just noting that it isn't just about line count.
> > It isalos much clearer to understand that a FOLL flag changes the
> > behavior of how GUP works rather than some weirdo NULL argument.
>
> The whole "locked" parameter handling is weird. I don't think adding a new
> FOLL_ internal flag on top particularly improves the situation ... at least
> before, the logic around that "locked" parameter handling was
> self-contained. Self-contained weirdness.
Well it has become less self contained now. Locked is sprinkled
everywhere, and the main purpose of locked has now changed to
primarily be about managing the mmap_sem, ie we now lock it
automatically for *locked=0
So the special meaning of 'you can unlock while guppping' has been
really obscured. With FOLL_UNLOCKABLE it is clear, search on that and
you will find the few users and the one place that implements it.
Jason
next prev parent reply other threads:[~2023-01-23 18:07 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-17 15:58 [PATCH 0/8] Simplify the external interface for GUP Jason Gunthorpe
2023-01-17 15:58 ` [PATCH 1/8] mm/gup: have internal functions get the mmap_read_lock() Jason Gunthorpe
2023-01-19 11:16 ` Mike Rapoport
2023-01-19 21:19 ` John Hubbard
2023-01-19 22:40 ` John Hubbard
2023-01-20 14:47 ` Jason Gunthorpe
2023-01-17 15:58 ` [PATCH 2/8] mm/gup: don't call __gup_longterm_locked() if FOLL_LONGTERM cannot be set Jason Gunthorpe
2023-01-19 22:24 ` John Hubbard
2023-01-17 15:58 ` [PATCH 3/8] mm/gup: simplify the external interface functions and consolidate invariants Jason Gunthorpe
2023-01-19 11:17 ` Mike Rapoport
2023-01-20 2:51 ` John Hubbard
2023-01-20 14:58 ` Jason Gunthorpe
2023-01-20 18:45 ` John Hubbard
2023-01-17 15:58 ` [PATCH 4/8] mm/gup: add an assertion that the mmap lock is locked Jason Gunthorpe
2023-01-20 3:08 ` John Hubbard
2023-01-20 15:44 ` Jason Gunthorpe
2023-01-17 15:58 ` [PATCH 5/8] mm/gup: add FOLL_UNLOCK Jason Gunthorpe
2023-01-19 11:18 ` Mike Rapoport
2023-01-20 13:45 ` Jason Gunthorpe
2023-01-20 14:58 ` Mike Rapoport
2023-01-20 19:02 ` John Hubbard
2023-01-23 11:37 ` David Hildenbrand
2023-01-23 17:58 ` Jason Gunthorpe
2023-01-23 22:22 ` John Hubbard
2023-01-24 13:08 ` David Hildenbrand
2023-01-17 15:58 ` [PATCH 6/8] mm/gup: make locked never NULL in the internal GUP functions Jason Gunthorpe
2023-01-20 19:19 ` John Hubbard
2023-01-21 0:21 ` Jason Gunthorpe
2023-01-23 11:35 ` David Hildenbrand
2023-01-23 12:44 ` Jason Gunthorpe
2023-01-23 12:59 ` David Hildenbrand
2023-01-23 18:07 ` Jason Gunthorpe [this message]
2023-01-17 15:58 ` [PATCH 7/8] mm/gup: remove pin_user_pages_fast_only() Jason Gunthorpe
2023-01-20 19:23 ` John Hubbard
2023-01-23 11:31 ` David Hildenbrand
2023-01-17 15:58 ` [PATCH 8/8] mm/gup: make get_user_pages_fast_only() return the common return value Jason Gunthorpe
2023-01-20 19:27 ` John Hubbard
2023-01-23 11:33 ` David Hildenbrand
2023-01-19 11:18 ` [PATCH 0/8] Simplify the external interface for GUP Mike Rapoport
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=Y87M6eFsOdW1pLwy@nvidia.com \
--to=jgg@nvidia.com \
--cc=apopple@nvidia.com \
--cc=david@redhat.com \
--cc=jhubbard@nvidia.com \
--cc=linux-mm@kvack.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.