On Thu, 15 Feb 2018, Matthew Wilcox wrote: > > The inducing of releasing memory back is not there but you can run SLUB > > with MAX_ORDER allocations by passing "slab_min_order=9" or so on bootup. > > This is subtly different from the idea that I had. If you set > slub_min_order to 9, then slub will allocate 2MB pages for each slab, > so allocating one object from kmalloc-32 and one object from dentry will > cause 4MB to be taken from the system. Right. > 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. What we could do is add a readonly allocation mode for those objects for which we know that are never freed. Those could be combined into 2M blocks. Or an allocation mode where we would free a whole bunch of objects in one go. If we can mark those allocs then they could be satisfied from the same block. -- 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
