On 8/30/21 23:38, Matthew Wilcox wrote: > I think something that might actually help is if we added a pair of new > GFP flags, __GFP_FAST and __GFP_DENSE. Dense allocations are those which > are expected to live for a long time, and so the page allocator should > try to group them with other dense allocations. Slab and page tables > should use DENSE, along with things like superblocks, or fs bitmaps where > the speed of allocation is almost unimportant, but attempting to keep > them out of the way of other allocations is useful. Fast allocations > are for allocations which should not live for very long. The speed of > allocation dominates, and it's OK if the allocation gets in the way of > defragmentation for a while. Note we used to have GFP_TEMPORARY, but it didn't really work out: https://lwn.net/Articles/732107/ > An example of another allocator that could care about DENSE vs FAST > would be vmalloc. Today, it does: > > if (array_size > PAGE_SIZE) { > area->pages = __vmalloc_node(array_size, 1, nested_gfp, node, > area->caller); > } else { > area->pages = kmalloc_node(array_size, nested_gfp, node); > } > > That's actually pretty bad; if you have, say, a 768kB vmalloc space, > you need a 12kB array. We currently allocate 16kB for the array, when we > could use alloc_pages_exact() to free the 4kB we're never going to use. > If this is GFP_DENSE, we know it's a long-lived allocation and we can > let somebody else use the extra 4kB. If it's not, it's probably not > worth bothering with. >
