Messages in this thread | | | Date | Tue, 17 Apr 2018 11:38:02 -0500 (CDT) | From | Christopher Lameter <> | Subject | Re: [PATCH RESEND] slab: introduce the flag SLAB_MINIMIZE_WASTE |
| |
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.
| |