On Wed, Apr 07, 2021 at 03:35:27AM +0100, Matthew Wilcox wrote: > On Tue, Apr 06, 2021 at 06:44:49PM -0700, Michel Lespinasse wrote: > > In the speculative case, call the vm_ops->fault() method from within > > an rcu read locked section, and verify the mmap sequence lock at the > > start of the section. A match guarantees that the original vma is still > > valid at that time, and that the associated vma->vm_file stays valid > > while the vm_ops->fault() method is running. > > > > Note that this implies that speculative faults can not sleep within > > the vm_ops->fault method. We will only attempt to fetch existing pages > > from the page cache during speculative faults; any miss (or prefetch) > > will be handled by falling back to non-speculative fault handling. > > > > The speculative handling case also does not preallocate page tables, > > as it is always called with a pre-existing page table. > > I still don't understand why you want to do this. The speculative > fault that doesn't do I/O is already here, and it's called ->map_pages > (which I see you also do later). So what's the point of this patch? I have to admit I did not give much tought about which path would be generally most common here. The speculative vm_ops->fault path would be used: - for private mapping write faults, - when fault-around is disabled (probably an uncommon case in general, but actually common at Google). That said, I do think your point makes sense in general, espicially if this could help avoid the per-filesystem enable bit.
