Re: Splitting the mmap_sem

[Michal Hocko <mhocko@suse.com>]

On Thu 09-01-20 14:56:48, Vlastimil Babka wrote:
> +CC
> 
> On 1/7/20 3:27 PM, Kirill A. Shutemov wrote:
> >>>> 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()?
> > 
> > I don't have strong preference here.
> 
> I think it's generally a good idea to have the memalloc_() scoping.

I also think there are going to be other usecases where NOWAIT scoping
would be interesting. I am not sure this is the case for the page tables
allocation though. I might misremember but RCU based VMA handling has
been considered in the past. I do not remember details but there were
some problems and page tables allocation is not the biggest one.

> However, we use the PF_* flags where it now seems 30 out of 32 are used,
> and MEMALLOC* already occupies 3 of those.

This shouldn't be a big deal. Adding a single int to the struct page
shouldn't be terribly hard.

-- 
Michal Hocko
SUSE Labs