On Mon, 16 Apr 2018, Vlastimil Babka wrote: > >> Its not a senseless increase. The more objects you fit into a slab page > >> the higher the performance of the allocator. > > It's not universally without a cost. It might increase internal > fragmentation of the slabs, if you end up with lots of 4MB pages > containing just few objects. Thus, waste of memory. You also consume > high-order pages that could be used elsewhere. If you fail to allocate > 4MB, then what's the fallback, order-0? I doubt it's "the highest > available order". Thus, a more conservative choice e.g. order-3 will > might succeed more in allocating order-3, while a choice of 4MB will > have many order-0 fallbacks. Obviously there is a cost. But here the subsystem has a fallback. > I think it should be possible without a new flag. The slub allocator > could just balance priorities (performance vs memory efficiency) better. > Currently I get the impression that "slub_max_order" is a performance > tunable. Let's add another criteria for selecting an order, that would > try to pick an order to minimize wasted space below e.g. 10% with some > different kind of max order. Pick good defaults, add tunables if you must. There is also slub_min_objects. > I mean, anyone who's creating a cache for 640KB objects most likely > doesn't want to waste another 384KB by each such object. They shouldn't > have to add a flag to let the slub allocator figure out that using 2MB > pages is the right thing to do here. I agree if we do this then preferably without a flag.
