On Thu, 15 Feb 2018, Matthew Wilcox wrote: > What I was proposing was an intermediate page allocator where slab would > request 2MB for its own uses all at once, then allocate pages from that to > individual slabs, so allocating a kmalloc-32 object and a dentry object > would result in 510 pages of memory still being available for any slab > that needed it. > A type of memory arena built between the page allocator and slab allocator. The issue that I see with this is eventually there's going to be low on memory situations where memory needs to be reclaimed from these arena pages. We can free individual pages back to the buddy allocator, but have no control over whether an entire pageblock can be freed back. So now we have MIGRATE_MOVABLE or MIGRATE_UNMOVABLE pageblocks with some user pages and some slab pages, and we've reached the same fragmentation issue in a different way. After that, it will become more difficult for the slab allocator to request a page of pageblock_order. Other than the stranding issue of MIGRATE_UNMOVABLE pages on pcps, the page allocator currently does well in falling back to other migratetypes but there isn't any type of slab reclaim or defragmentation done in the background to try to free up as much memory from that now-MIGRATE_UNMOVABLE pageblock as possible. We have patches that do that, but as I mentioned before it can affect the performance of the page allocator because it drains pcps on fallback and it does kcompactd compaction in the background even if you don't need order-9 memory later (or you've defragmented needlessly when more slab is just going to be allocated anyway). -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
