On Fri, 16 Feb 2018, Matthew Wilcox wrote: > On Fri, Feb 16, 2018 at 09:44:25AM -0600, Christopher Lameter wrote: > > 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. > > > > Well thats not really going to work since you would be mixing objects of > > different sizes which may present more fragmentation problems within the > > 2M later if they are freed and more objects are allocated. > > I don't understand this response. I'm not suggesting mixing objects > of different sizes within the same page. The vast majority of slabs > use order-0 pages, a few use order-1 pages and larger sizes are almost > unheard of. I'm suggesting the slab have it's own private arena of pages > that it uses for allocating pages to slabs; when an entire page comes > free in a slab, it is returned to the arena. When the arena is empty, > slab requests another arena from the page allocator. This just shifts the fragmentation problem because the 2M page cannot be released until all 4k or 8k pages within that 2M page are freed. How is that different from the page allocator which cannot coalesce an 2M page until all fragments have been released? The kernelcore already does something similar by limiting the general unmovable allocs to a section of memory. > If you're concerned about order-0 allocations fragmenting the arena > for order-1 slabs, then we could have separate arenas for order-0 and > order-1. But there should be no more fragmentation caused by sticking > within an arena for page allocations than there would be by spreading > slab allocations across all memory. We avoid large frames at this point but they are beneficial to pack objects tighter and also increase performance. Maybe what we should do is raise the lowest allocation size instead and allocate 2^x groups of pages to certain purposes? I.e. have a base allocation size of 16k and if the alloc was a page cache page then use the remainder for the neigboring pages. Similar things could be done for the page allocator. Raising the minimum allocation size may allow us to reduce the sizes necessary to be allocated at the price of loosing some memory. On large systems this may not matter much. -- 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
