Messages in this thread | | | Date | Thu, 9 Mar 2023 06:31:25 +0000 | From | Hyeonggon Yoo <> | Subject | Re: [RFC PATCH 1/5] mm: intorduce __GFP_UNMAPPED and unmapped_alloc() |
| |
On Wed, Mar 08, 2023 at 11:41:02AM +0200, Mike Rapoport wrote: > From: "Mike Rapoport (IBM)" <rppt@kernel.org> > > When set_memory or set_direct_map APIs used to change attribute or > permissions for chunks of several pages, the large PMD that maps these > pages in the direct map must be split. Fragmenting the direct map in such > manner causes TLB pressure and, eventually, performance degradation. > > To avoid excessive direct map fragmentation, add ability to allocate > "unmapped" pages with __GFP_UNMAPPED flag that will cause removal of the > allocated pages from the direct map and use a cache of the unmapped pages. > > This cache is replenished with higher order pages with preference for > PMD_SIZE pages when possible so that there will be fewer splits of large > pages in the direct map. > > The cache is implemented as a buddy allocator, so it can serve high order > allocations of unmapped pages.
Hello,
To me it seems unnecessary to increase pageblock bitmap size just to distinguish if it is allocated with __GFP_UNMAPPED.
I think this can be implemented as an independent cache on top of buddy allocator, and introducing new API for unmapped page allocation and freeing?
Thanks, Hyeonggon
| |