On Wed, Jan 24, 2018 at 8:01 PM, Bart Van Assche <Bart.VanAssche@xxxxxxx> wrote: > On Wed, 2018-01-24 at 19:56 -0800, Dan Williams wrote: >> The get_user_pages_longterm() api was recently added as a stop-gap >> measure to prevent applications from growing dependencies on the >> ability to to pin DAX-mapped filesystem blocks for RDMA indefinitely >> with no ongoing coordination with the filesystem. This 'longterm' >> pinning is also problematic for the non-DAX VMA case where the core-mm >> needs a time bounded way to revoke a pin and manipulate the physical >> pages. While existing RDMA applications have already grown the >> assumption that they can pin page-cache pages indefinitely, the fact >> that we are breaking this assumption for filesystem-dax presents an >> opportunity to deprecate the 'indefinite pin' mechanisms and move to a >> general interface that supports pin revocation. >> >> While RDMA may grow an explicit Infiniband-verb for this 'memory >> registration with lease' semantic, it seems that this problem is >> bigger than just RDMA. At LSF/MM it would be useful to have a >> discussion between fs, mm, dax, and RDMA folks about addressing this >> problem at the core level. >> >> Particular people that would be useful to have in attendance are >> Michal Hocko, Christoph Hellwig, and Jason Gunthorpe (cc'd). > > Is on demand paging sufficient as a solution for your use case... No, in 3 dimensions since there is a need to support non-ODP RDMA hardware, hypervisors want to coordinate DMA for guests, and non-RDMA hardware also pins memory indefinitely like V4L2. So it's bigger than RDMA, but that will likely be the first consumer of this 'longterm pin' mechanism. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>
