On Fri, May 08, 2020 at 01:17:55PM -0700, Ralph Campbell wrote: > On 5/8/20 12:59 PM, Matthew Wilcox wrote: > > On Fri, May 08, 2020 at 12:20:03PM -0700, Ralph Campbell wrote: > > > hmm_range_fault() returns an array of page frame numbers and flags for > > > how the pages are mapped in the requested process' page tables. The PFN > > > can be used to get the struct page with hmm_pfn_to_page() and the page size > > > order can be determined with compound_order(page) but if the page is larger > > > than order 0 (PAGE_SIZE), there is no indication that the page is mapped > > > using a larger page size. To be fully general, hmm_range_fault() would need > > > to return the mapping size to handle cases like a 1GB compound page being > > > mapped with 2MB PMD entries. However, the most common case is the mapping > > > size the same as the underlying compound page size. > > > This series adds a new output flag to indicate this so that callers know it > > > is safe to use a large device page table mapping if one is available. > > > Nouveau and the HMM tests are updated to use the new flag. > > > > This explanation doesn't make any sense. It doesn't matter how somebody > > else has it mapped; if it's a PMD-sized page, you can map it with a > > 2MB mapping. > > Sure, the I/O will work OK, but is it safe? > Copy on write isn't an issue? splitting a PMD in one process due to > mprotect of a shared page will cause other process' page tables to be split > the same way? Are you saying that if you call this function on an address range of a process which has done COW of a single page in the middle of a THP, you want to return with this flag clear, but if the THP is still intact, you want to set this flag? > Recall that these are system memory pages that could be THPs, shmem, hugetlbfs, > mmap shared file pages, etc.
