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 ...
