Re: [PATCH 0/5] make slab gfp fair

Christoph Lameter
2007-05-14T19:57:12Z

On Mon, 14 May 2007, Peter Zijlstra wrote:

> > You can pull the big switch (only on a SLUB slab I fear) to switch
> > off the fast path. Do SetSlabDebug() when allocating a precious
> > allocation that should not be gobbled up by lower level processes.
> > Then you can do whatever you want in the __slab_alloc debug section and we
> > wont care because its not the hot path.
>
> One allocator is all I need; it would just be grand if all could be
> supported.
>
> So what you suggest is not placing the 'emergency' slab into the regular
> place so that normal allocations will not be able to find it. Then if an
> emergency allocation cannot be satified by the regular path, we fall
> back to the slow path and find the emergency slab.

Hmmm.. Maybe we could do that.... But what I had in mind was simply to
set a page flag (DebugSlab()) if you know in alloc_slab that the slab
should be only used for emergency allocation. If DebugSlab is set then the
fastpath will not be called. You can trap all allocation attempts and
insert whatever fancy logic you want in the debug path since its not
performance critical.

> The thing is; I'm not needing any speed, as long as the machine stay
> alive I'm good. However others are planing to build a full reserve based
> allocator to properly fix the places that now use __GFP_NOFAIL and
> situation such as in add_to_swap().

Well I have version of SLUB here that allows you do redirect the alloc
calls at will. Adds a kmem_cache_ops structure and in the kmem_cache_ops
structure you can redirect allocation and freeing of slabs (not objects!)
at will. Would that help?