From: Jason Gunthorpe <jgg@ziepe.ca>
To: John Hubbard <jhubbard@nvidia.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
linux-mm <linux-mm@kvack.org>,
Dan Williams <dan.j.williams@intel.com>,
Ira Weiny <ira.weiny@intel.com>,
Pavel Tatashin <pasha.tatashin@soleen.com>
Subject: Re: [PATCH] mm/gup: remove the vma allocation from gup_longterm_locked()
Date: Fri, 4 Dec 2020 20:27:37 -0400 [thread overview]
Message-ID: <20201205002737.GG5487@ziepe.ca> (raw)
In-Reply-To: <99dc35be-62c1-56b6-ae37-024a2b2ab81d@nvidia.com>
On Fri, Dec 04, 2020 at 01:36:27PM -0800, John Hubbard wrote:
> On 12/4/20 11:39 AM, Jason Gunthorpe wrote:
> > Long ago there wasn't a FOLL_LONGTERM flag so this DAX check was done by
> > post-processing the VMA list.
> >
> > These days it is trivial to just check each VMA to see if it is DAX before
> > processing it inside __get_user_pages() and return failure if a DAX VMA is
> > encountered with FOLL_LONGTERM.
> >
> > Removing the allocation of the VMA list is a significant speed up for many
> > call sites.
>
> This all looks nice, and if you actually have quantifiable perf results as you
> imply above, then let's put them right here.
I don't really have a good perf setup, it is just obvious that
removing the calls to the allocator will speed up cases like RDMA that
call gup in batches of 512 pages, or vfio which calls in batches of
1. :)
Jason
next prev parent reply other threads:[~2020-12-05 0:27 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-04 19:39 [PATCH] mm/gup: remove the vma allocation from gup_longterm_locked() Jason Gunthorpe
2020-12-04 21:36 ` John Hubbard
2020-12-05 0:27 ` Jason Gunthorpe [this message]
2020-12-04 22:19 ` Ira Weiny
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=20201205002737.GG5487@ziepe.ca \
--to=jgg@ziepe.ca \
--cc=akpm@linux-foundation.org \
--cc=dan.j.williams@intel.com \
--cc=ira.weiny@intel.com \
--cc=jhubbard@nvidia.com \
--cc=linux-mm@kvack.org \
--cc=pasha.tatashin@soleen.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 NNTP newsgroup(s).