On 3/14/19 2:06 AM, Jan Kara wrote: > On Wed 13-03-19 19:21:37, Christopher Lameter wrote: >> On Wed, 13 Mar 2019, Christoph Hellwig wrote: >> >>> On Wed, Mar 13, 2019 at 09:11:13AM +1100, Dave Chinner wrote: >>>> On Tue, Mar 12, 2019 at 03:39:33AM -0700, Ira Weiny wrote: >>>>> IMHO I don't think that the copy_file_range() is going to carry us through the >>>>> next wave of user performance requirements. RDMA, while the first, is not the >>>>> only technology which is looking to have direct access to files. XDP is >>>>> another.[1] >>>> >>>> Sure, all I doing here was demonstrating that people have been >>>> trying to get local direct access to file mappings to DMA directly >>>> into them for a long time. Direct Io games like these are now >>>> largely unnecessary because we now have much better APIs to do >>>> zero-copy data transfer between files (which can do hardware offload >>>> if it is available!). >>> >>> And that is just the file to file case. There are tons of other >>> users of get_user_pages, including various drivers that do large >>> amounts of I/O like video capture. For them it makes tons of sense >>> to transfer directly to/from a mmap()ed file. >> >> That is very similar to the RDMA case and DAX etc. We need to have a way >> to tell a filesystem that this is going to happen and that things need to >> be setup for this to work properly. > > The way to tell filesystem what's happening is exactly what we are working > on with these patches... > >> But if that has not been done then I think its proper to fail a long term >> pin operation on page cache pages. Meaning the regular filesystems >> maintain control of whats happening with their pages. > > And as I mentioned in my other email, we cannot just fail the pin for > pagecache pages as that would regress existing applications. > > Honza > Christopher L, Are you OK with this approach now? If so, I'd like to collect any additional ACKs people are willing to provide, and ask Andrew to consider this first patch for 5.2, so we can get started. thanks, -- John Hubbard NVIDIA
