• Christoph Lameter's avatar
    Categorize GFP flags · 6cb06229
    Christoph Lameter authored
    The function of GFP_LEVEL_MASK seems to be unclear.  In order to clear up
    the mystery we get rid of it and replace GFP_LEVEL_MASK with 3 sets of GFP
    GFP_RECLAIM_MASK	Flags used to control page allocator reclaim behavior.
    GFP_CONSTRAINT_MASK	Flags used to limit where allocations can occur.
    GFP_SLAB_BUG_MASK	Flags that the slab allocator BUG()s on.
    These replace the uses of GFP_LEVEL mask in the slab allocators and in
    The use of the flags not included in these sets may occur as a result of a
    slab allocation standing in for a page allocation when constructing scatter
    gather lists.  Extraneous flags are cleared and not passed through to the
    page allocator.  __GFP_MOVABLE/RECLAIMABLE, __GFP_COLD and __GFP_COMP will
    now be ignored if passed to a slab allocator.
    Change the allocation of allocator meta data in SLAB and vmalloc to not
    pass through flags listed in GFP_CONSTRAINT_MASK.  SLAB already removes the
    __GFP_THISNODE flag for such allocations.  Generalize that to also cover
    vmalloc.  The use of GFP_CONSTRAINT_MASK also includes __GFP_HARDWALL.
    The impact of allocator metadata placement on access latency to the
    cachelines of the object itself is minimal since metadata is only
    referenced on alloc and free.  The attempt is still made to place the meta
    data optimally but we consistently allow fallback both in SLAB and vmalloc
    (SLUB does not need to allocate metadata like that).
    Allocator metadata may serve multiple in kernel users and thus should not
    be subject to the limitations arising from a single allocation context.
    [akpm@linux-foundation.org: fix fallback_alloc()]
    Signed-off-by: default avatarChristoph Lameter <clameter@sgi.com>
    Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
    Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
vmalloc.c 19.1 KB