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
