Re: [PATCH] mm/page_alloc: Avoid page allocator recursion with pagesets.lock held

[Matthew Wilcox <willy@infradead.org>]

On Thu, Jul 08, 2021 at 09:10:18AM -0400, Rafael Aquini wrote:
> > There are a number of ways it could be fixed. The page owner code could
> > be audited to strip GFP flags that allow sleeping but it'll impair the
> > functionality of PAGE_OWNER if allocations fail. The bulk allocator
> > could add a special case to release/reacquire the lock for prep_new_page
> > and lookup PCP after the lock is reacquired at the cost of performance.
> > The patches requiring prep could be tracked using the least significant

If we're nitpicking changelogs, then s/patches/pages/

> > bit and looping through the array although it is more complicated for
> > the list interface. The options are relatively complex and the second
> > one still incurs a performance penalty when PAGE_OWNER is active so this
> > patch takes the simple approach -- disable bulk allocation of PAGE_OWNER is
>                                                             ^^^^
> Minor nit: s/of/if
> 
> > active. The caller will be forced to allocate one page at a time incurring
> > a performance penalty but PAGE_OWNER is already a performance penalty.

The thought occurs that all pages allocated this way will have the same
stack.  Someone suitably motivated could:

 - Refcount the stacks managed by page_owner
 - Generate the stack in the caller of alloc_bulk
 - Pass the stack in to a new __set_page_owner()

That's a lot of work; I'm not going to do it, and I don't think Mel
should either.  But if someone's looking for something to do ...