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