Message ID | 20240411070157.3318425-1-vivek.kasireddy@intel.com (mailing list archive) |
---|---|
Headers | show |
Series | mm/gup: Introduce memfd_pin_folios() for pinning memfd folios | expand |
Hey Gerd, do you have any time to look at this series again, I think at v14 we should probably consider landing it. I'm happy to give Acked-by: Dave Airlie <airlied@redhat.com> for landing this via mm if it makes the most sense. One comment in passing, was I wonder if it makes sense for things like vm_map_ram to have a folio variant in the future, to avoid that pages temporary allocation. Dave. > Cc: David Hildenbrand <david@redhat.com> > Cc: Matthew Wilcox (Oracle) <willy@infradead.org> > Cc: Christoph Hellwig <hch@infradead.org> > Cc: Andrew Morton <akpm@linux-foundation.org> > Cc: Daniel Vetter <daniel.vetter@ffwll.ch> > Cc: Hugh Dickins <hughd@google.com> > Cc: Peter Xu <peterx@redhat.com> > Cc: Jason Gunthorpe <jgg@nvidia.com> > Cc: Gerd Hoffmann <kraxel@redhat.com> > Cc: Dongwon Kim <dongwon.kim@intel.com> > Cc: Junxiao Chang <junxiao.chang@intel.com> > > Vivek Kasireddy (8): > mm/gup: Introduce unpin_folio/unpin_folios helpers > mm/gup: Introduce check_and_migrate_movable_folios() > mm/gup: Introduce memfd_pin_folios() for pinning memfd folios > udmabuf: Use vmf_insert_pfn and VM_PFNMAP for handling mmap > udmabuf: Add back support for mapping hugetlb pages > udmabuf: Convert udmabuf driver to use folios > udmabuf: Pin the pages using memfd_pin_folios() API > selftests/udmabuf: Add tests to verify data after page migration > > drivers/dma-buf/udmabuf.c | 231 +++++++++---- > include/linux/memfd.h | 5 + > include/linux/mm.h | 5 + > mm/gup.c | 307 +++++++++++++++--- > mm/memfd.c | 35 ++ > .../selftests/drivers/dma-buf/udmabuf.c | 214 ++++++++++-- > 6 files changed, 659 insertions(+), 138 deletions(-) > > -- > 2.43.0 >
On Thu, May 23, 2024 at 01:13:11PM GMT, Dave Airlie wrote: > Hey > > Gerd, do you have any time to look at this series again, I think at > v14 we should probably consider landing it. Phew. Didn't follow recent MM changes closely, don't know much about folios beyond LWN coverage. The changes look sane to my untrained eye, I wouldn't rate that a 'review' though. The patch series structure looks a bit odd, with patch #5 adding hugetlb support, with the functions added being removed again in patch #7 after switching to folios. But maybe regression testing the series is easier that way ... Acked-by: Gerd Hoffmann <kraxel@redhat.com> take care, Gerd
Hi Gerd, Dave, > > On Thu, May 23, 2024 at 01:13:11PM GMT, Dave Airlie wrote: > > Hey > > > > Gerd, do you have any time to look at this series again, I think at > > v14 we should probably consider landing it. > > Phew. Didn't follow recent MM changes closely, don't know much about > folios beyond LWN coverage. The changes look sane to my untrained eye, > I wouldn't rate that a 'review' though. > > The patch series structure looks a bit odd, with patch #5 adding hugetlb > support, with the functions added being removed again in patch #7 after > switching to folios. But maybe regression testing the series is easier > that way ... Yes, regression testing is one reason. The other reason is to make it possible for patches #4 and #5 to be backported to older stable kernels in order to add back support for mapping hugetlbfs files without depending on folio related changes/patches. > > Acked-by: Gerd Hoffmann <kraxel@redhat.com> Thank you. Andrew has merged this series to his mm tree. Thanks, Vivek > > take care, > Gerd