On Wed, 2023-03-08 at 11:41 +0200, Mike Rapoport wrote: > From: "Mike Rapoport (IBM)" <rppt@xxxxxxxxxx> > > Hi, > > This is a third attempt to make page allocator aware of the direct > map > layout and allow grouping of the pages that must be unmapped from > the direct map. > > This a new implementation of __GFP_UNMAPPED, kinda a follow up for > this set: > > https://lore.kernel.org/all/20220127085608.306306-1-rppt@xxxxxxxxxx > > but instead of using a migrate type to cache the unmapped pages, the > current implementation adds a dedicated cache to serve __GFP_UNMAPPED > allocations. It seems a downside to having a page allocator outside of _the_ page allocator is you don't get all of the features that are baked in there. For example does secretmem care about numa? I guess in this implementation there is just one big cache for all nodes. Probably most users would want __GFP_ZERO. Would secretmem care about __GFP_ACCOUNT? I'm sure there is more, but I guess the question is, is the idea that these features all get built into unmapped-alloc at some point? The alternate approach is to have little caches for each usage like the grouped pages, which is probably less efficient when you have a bunch of them. Or solve it just for modules like the bpf allocator. Those are the tradeoffs for the approaches that have been explored, right?
