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
