Thread (34 messages) flat view 34 messages, 5 authors, 2019-02-13

Re: [PATCH 0/3] Add gup fast + longterm and use it in HFI1

From: Jason Gunthorpe <jgg@ziepe.ca>
Date: 2019-02-11 22:23:41
Also in: linux-mm, linux-rdma, lkml

On Mon, Feb 11, 2019 at 09:14:56PM +0000, Weiny, Ira wrote:
quoted
On Mon, Feb 11, 2019 at 12:16:40PM -0800, ira.weiny@intel.com wrote:
quoted
From: Ira Weiny <redacted>

NOTE: This series depends on my clean up patch to remove the write
parameter from gup_fast_permitted()[1]

HFI1 uses get_user_pages_fast() due to it performance advantages.
Like RDMA,
HFI1 pages can be held for a significant time.  But
get_user_pages_fast() does not protect against mapping of FS DAX pages.
If HFI1 can use the _fast varient, can't all the general RDMA stuff use it too?

What is the guidance on when fast vs not fast should be use?
Right now it can't because it holds mmap_sem across the call.  Once
Shiraz's patches are accepted removing the umem->hugetlb flag I
think we can change umem.c.
Okay, that make sense, we should change it when Shiraz's patches are
merged
 
Also, it specifies FOLL_FORCE which can't currently be specified
with gup fast.  One idea I had was to change get_user_pages_fast()
to use gup_flags instead of a single write flag.  But that proved to
be a very big cosmetic change across a lot of callers so I went this
way.
I think you should do it.. :)

Jason
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help