Re: [patch] mm, slab: avoid high-order slab pages when it does not reduce waste

[Vlastimil Babka]

On 10/16/18 5:17 PM, Christopher Lameter wrote:
>> I'm not necessarily approaching this from a performance point of view, but
>> rather as a means to reduce slab fragmentation when fallback to order-0
>> memory, especially when completely legitimate, is prohibited.  From a
>> performance standpoint, this will depend on separately on fragmentation
>> and contention on zone->lock which both don't exist for order-0 memory
>> until fallback is required and then the pcp are filled with up to
>> batchcount pages.
> Fragmentation is a performance issue and causes degradation of Linux MM
> performance over time.  There are pretty complex mechanism that need to be
> played against one another.
> 
> Come up with some metrics to get meaningful data that allows us to see the
> impact.

I don't think the patch as it is needs some special evaluation. SLAB's
current design is to keep gfporder at minimum that satisfies "Acceptable
internal fragmentation" of 1/8 of the allocated gfporder page (hm
arguably that should be also considered relatively to order-0 page, as
I've argued for the comparison done in this patch as well).

In such design it's simply an oversight that we increase the gfporder in
cases when it doesn't improve the internal fragmentation metric, and it
should be straightforward decision to stop doing it.

I.e. the benefits vs drawbacks of higher order allocations for SLAB are
out of scope here. It would be nice if somebody evaluated them, but the
potential resulting change would be much larger than what concerns this
patch. But it would arguably also make SLAB more like SLUB, which you
already questioned at some point...

Vlastimil