From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jason Gunthorpe Subject: Re: [PATCH 2/3] mm/gup: Introduce get_user_pages_fast_longterm() Date: Mon, 11 Feb 2019 16:25:10 -0700 Message-ID: <20190211232510.GP24692@ziepe.ca> References: <20190211201643.7599-1-ira.weiny@intel.com> <20190211201643.7599-3-ira.weiny@intel.com> <20190211203916.GA2771@ziepe.ca> <20190211212652.GA7790@iweiny-DESK2.sc.intel.com> <20190211215238.GA23825@iweiny-DESK2.sc.intel.com> <20190211220658.GH24692@ziepe.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org To: Dan Williams Cc: Ira Weiny , John Hubbard , linux-rdma , Linux Kernel Mailing List , Linux MM , Daniel Borkmann , Davidlohr Bueso , Netdev , Mike Marciniszyn , Dennis Dalessandro , Doug Ledford , Andrew Morton , "Kirill A. Shutemov" List-Id: linux-rdma@vger.kernel.org On Mon, Feb 11, 2019 at 02:55:10PM -0800, Dan Williams wrote: > > I also wonder if someone should think about making fast into a flag > > too.. > > > > But I'm not sure when fast should be used vs when it shouldn't :( > > Effectively fast should always be used just in case the user cares > about performance. It's just that it may fail and need to fall back to > requiring the vma. But the fall back / slow path is hidden inside the API, so when should the caller care? ie when should the caller care to use gup_fast vs gup_unlocked? (the comments say they are the same, but this seems to be a mistake) Based on some of the comments in the code it looks like this API is trying to convert itself into: long get_user_pages_locked(struct task_struct *tsk, struct mm_struct *mm, unsigned long start, unsigned long nr_pages, unsigned int gup_flags, struct page **pages, struct vm_area_struct **vmas, bool *locked) long get_user_pages_unlocked(struct task_struct *tsk, struct mm_struct *mm, unsigned long start, unsigned long nr_pages, unsigned int gup_flags, struct page **pages) (and maybe a FOLL_FAST if there is some reason we have _fast and _unlocked) The reason I ask, is that if there is no reason for fast vs unlocked then maybe Ira should convert HFI to use gup_unlocked and move the 'fast' code into unlocked? ie move incrementally closer to the desired end-state here. Jason