On Tue, Jun 16, 2015 at 04:28:30PM -0600, Toshi Kani wrote: > DAX has the following issues in a shared or read-only private > mmap'd file. > - mmap(MAP_POPULATE) does not pre-fault > - mlock() fails with -ENOMEM > > DAX uses VM_MIXEDMAP for mmap'd files, which do not have struct > page associated with the ranges. Both MAP_POPULATE and mlock() > call __mm_populate(), which in turn calls __get_user_pages(). > Because __get_user_pages() requires a valid page returned from > follow_page_mask(), MAP_POPULATE and mlock(), i.e. FOLL_POPULATE, > fail in the first page. > > Change __get_user_pages() to proceed FOLL_POPULATE when the > translation is set but its page does not exist (-EFAULT), and > @pages is not requested. With that, MAP_POPULATE and mlock() > set translations to the requested range and complete successfully. > > MAP_POPULATE still provides a major performance improvement to > DAX as it will avoid page faults during initial access to the > pages. > > mlock() continues to set VM_LOCKED to vma and populate the range. > Since there is no struct page, the range is pinned without marking > pages mlocked. > > Note, MAP_POPULATE and mlock() already work for a write-able > private mmap'd file on DAX since populate_vma_page_range() breaks > COW, which allocates page caches. I don't think that's true in all cases. We would fail to break COW for mlock() if the mapping is populated with read-only entries by the mlock() time. In this case follow_page_mask() would fail with -EFAULT and faultin_page() will never executed. -- Kirill A. Shutemov -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
