On Tue, 2021-08-24 at 16:02 +0300, Mike Rapoport wrote: > > We probably want to exclude GFP_ATOMIC before calling into CPA > > unless > > debug page alloc is on, because it may need to split and sleep for > > the > > allocation. There is a page table allocation with GFP_ATOMIC passed > > actually. > > Looking at the callers of alloc_low_pages() it seems that GFP_ATOMIC > there > is stale... Well two actually, there is also spp_getpage(). I tried to determine if that was also stale but wasn't confident. There were a lot of paths in. > > > In my next series of this I added support for GFP_ATOMIC to this > > code, > > but that solution should only work for permission changing grouped > > page > > allocators in the protected page tables case where the direct map > > tables are handled differently. As a general solution though > > (that's > > the long term intention right?), GFP_ATOMIC might deserve some > > consideration. > > ... but for the general solution GFP_ATOMIC indeed deserves some > consideration. > > > The other thing is we probably don't want to clean out the atomic > > reserves and add them to a cache just for one page. I opted to just > > convert one page in the GFP_ATOMIC case. > > > Do you mean to allocate one page in GFP_ATOMIC case and bypass high > order > allocation? > But the CPA split is still necessary here, isn't it? Yes, grabs one atomic page and fragments it in the case of no pages in the grouped page cache. The CPA split is necessary still, but it should be ok because of the special way direct map page table allocations are handled for pks tables. Has not been reviewed by anyone yet, and wouldn't work as a general solution anyway.
