Re: Splitting the mmap_sem

[Matthew Wilcox <willy@infradead.org>]

On Tue, Jan 07, 2020 at 03:34:15PM +0300, Kirill A. Shutemov wrote:
> On Mon, Jan 06, 2020 at 02:09:10PM -0800, Matthew Wilcox wrote:
> > On Thu, Dec 12, 2019 at 07:40:02AM -0800, Matthew Wilcox wrote:
> > > > > We currently only have one ->map_pages() callback, and it's
> > > > > filemap_map_pages().  It only needs to sleep in one place -- to allocate
> > > > > a PTE table.  I think that can be allocated ahead of time if needed.
> > > > 
> > > > No, filemap_map_pages() doesn't sleep. It cannot. Whole body of the
> > > > function is under rcu_read_lock(). It uses pre-allocated page table.
> > > > See do_fault_around().
> > > 
> > > Oh, thank you!  That makes the ->map_pages() optimisation already workable
> > > with no changes.
> > 
> > I've been thinking about this some more, and we have a bit of a tough time
> > allocating page table entries while holding the RCU read lock.  There's
> > no GFP flags to the p??_alloc() functions, so we can't specify GFP_NOWAIT.
> > 
> > Option 1: Add 'prealloc_pmd' and 'prealloc_pud' to the vm_fault (to go
> > with prealloc_pte).  Allocate them before taking the RCU lock to walk
> > the VMA tree.  This will be a bit of reordering as we currently take
> > the mmap_sem, walk the VMA tree, then walk the page tables once we know
> > we have a good VMA.  I don't see a problem with doing that, but others
> > may differ.
> 
> I expect preallocating all these page tables just-in-case would have
> measuable performance impact. Current code only preallocates PTE page
> table if sees pmd_none().

Right, and we'd only preallocate those tables if we see pud_none() and
p4d_none().  Which is why we'd need to walk the page tables before
walking the VMA tree.

> We may first check if this branch of the tree is present. But I'm not sure
> how efficient it can be. And we still need to protect from freeing
> these page tables from under us.

Do we free page tables once they've been inserted, other than at
process exit?

> > Option 2: Add a memalloc_nowait_save/restore API to go along
> > with nofs and noio.  That way, we can take the RCU read lock, call
> > memalloc_nowait_save(), and walk the VMA tree and the page tables in
> > the current order.  There's an increased chance of memory allocation of
> > page tables failing, so we'll have to risk that and do a retry with the
> > reference count held on the VMA if we need to sleep to allocate memory.
> > 
> > Option 3: Variant of 2 where we add GFP flags to the p??_alloc()
> > functions.
> 
> I think this is the most reasonable way. If we are low of memory, latency
> is not on the top of priorities.

You prefer adding GFP flags over adding a memalloc_nowait_save()?