On Tue 07-02-17 08:56:56, Dan Williams wrote: > On Tue, Feb 7, 2017 at 12:44 AM, Kirill A. Shutemov > <kirill@xxxxxxxxxxxxx> wrote: > > On Mon, Feb 06, 2017 at 09:30:22AM -0800, Dan Williams wrote: > >> On Mon, Feb 6, 2017 at 9:27 AM, Christoph Hellwig <hch@xxxxxxxxxxxxx> wrote: > >> > On Mon, Feb 06, 2017 at 08:24:48AM -0800, Dan Williams wrote: > >> >> > Also can be use this opportunity > >> >> > to fold ->huge_fault into ->fault? > > > > BTW, for tmpfs we already use ->fault for both small and huge pages. > > If ->fault returned THP, core mm look if it's possible to map the page as > > huge in this particular VMA (due to size/alignment). If yes mm maps the > > page with PMD, if not fallback to PTE. > > > > I think it would be nice to do the same for DAX: filesystem provides core > > mm with largest page this part of file can be mapped with (base aligned > > address + lenght for DAX) and core mm sort out the rest. > > For DAX we would need plumb pfn_t into the core mm so that we have the > PFN_DEV and PFN_MAP flags beyond the raw pfn. So we can pass necessary information through struct vm_fault rather easily. However due to DAX locking we cannot really "return" pfn for generic code to install (we need to unlock radix tree locks after modifying page tables). So if we want generic code to handle PFNs what needs to be done is to teach finish_fault() to handle pfn_t which is passed to it and install it in page tables. Long term we could transition all page fault handlers (at least the non-trivial ones) to using finish_fault() which would IMO make the code flow easier to follow and export less of MM internals into drivers. However there's so many fault handlers that I didn't have a good motivation to do that yet. Honza -- Jan Kara <jack@xxxxxxxx> SUSE Labs, CR -- To unsubscribe from this list: send the line "unsubscribe linux-xfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
