On Fri, Sep 06, 2019 at 04:52:15PM +0300, Kirill A. Shutemov wrote: > On Fri, Sep 06, 2019 at 06:41:45AM -0700, Matthew Wilcox wrote: > > On Fri, Sep 06, 2019 at 03:59:28PM +0300, Kirill A. Shutemov wrote: > > > > + * - FGP_PMD: We're only interested in pages at PMD granularity. If there > > > > + * is no page here (and FGP_CREATE is set), we'll create one large enough. > > > > + * If there is a smaller page in the cache that overlaps the PMD page, we > > > > + * return %NULL and do not attempt to create a page. > > > > > > Is it really the best inteface? > > > > > > Maybe allow user to ask bitmask of allowed orders? For THP order-0 is fine > > > if order-9 has failed. > > > > That's the semantics that filemap_huge_fault() wants. If the page isn't > > available at order-9, it needs to return VM_FAULT_FALLBACK (and the VM > > will call into filemap_fault() to handle the regular sized fault). > > Ideally, we should not have division between ->fault and ->huge_fault. > Integrating them together will give a shorter fallback loop and more > flexible inteface here would give benefit. > > But I guess it's out-of-scope of the patchset. Heh, just a little bit ... there are about 150 occurrences of vm_operations_struct in the kernel, and I don't fancy one bit converting them all to use ->huge_fault instead of ->fault!
