On Tue, 17 Apr 2018, Vlastimil Babka wrote: > On 04/17/2018 04:45 PM, Christopher Lameter wrote:
> > But then higher order allocs are generally seen as problematic. > > I think in this case they are better than wasting/fragmenting 384kB for > 640kB object. Well typically we have suggested that people use vmalloc in the past. > > Note that SLUB will fall back to smallest order already if a failure > > occurs so increasing slub_max_order may not be that much of an issue. > > > > Maybe drop the max order limit completely and use MAX_ORDER instead? > > For packing, sure. For performance, please no (i.e. don't try to > allocate MAX_ORDER for each and every cache). No of course not. We would have to modify the order selection on kmem cache creation. > > That > > means that callers need to be able to tolerate failures. > > Is it any different from now? I suppose there would still be > smallest-order fallback involved in sl*b itself? And if your allocation > is so large it can fail even with the fallback (i.e. >= costly order), > you need to tolerate failures anyway? Failures can occur even with < costly order as far as I can telkl. Order 0 is the only safe one. > One corner case I see is if there is anyone who would rather use their > own fallback instead of the space-wasting smallest-order fallback. > Maybe we could map some GFP flag to indicate that. Well if you have a fallback then maybe the slab allocator should not fall back on its own but let the caller deal with it. -- dm-devel mailing list dm-devel@redhat.com https://www.redhat.com/mailman/listinfo/dm-devel
