Re: [PATCH 02/15] mm: sl[au]b: Add knowledge of PFMEMALLOC reservepages

[Mel Gorman]

On Fri, Feb 10, 2012 at 04:07:57PM -0600, Christoph Lameter wrote:
> Proposal for a patch for slub to move the pfmemalloc handling out of the
> fastpath by simply not assigning a per cpu slab when pfmemalloc processing
> is going on.
> 
> 
> 
> Subject: [slub] Fix so that no mods are required for the fast path
> 
> Remove the check for pfmemalloc from the alloc hotpath and put the logic after
> the election of a new per cpu slab.
> 
> For a pfmemalloc page do not use the fast path but force use of the slow
> path (which is also used for the debug case).
> 
> Signed-off-by: Christoph Lameter <cl@xxxxxxxxx>
> 

This weakens pfmemalloc processing in the following way

1. Process that is performance network swap calls __slab_alloc.
   pfmemalloc_match is true so the freelist is loaded and
   c->freelist is now pointing to a pfmemalloc page
2. Process that is attempting normal allocations calls slab_alloc,
   finds the pfmemalloc page on the freelist and uses it because it
   did not check pfmemalloc_match()

The patch allows non-pfmemalloc allocations to use pfmemalloc pages with
the kmalloc slabs being the most vunerable caches on the grounds they are
most likely to have a mix of pfmemalloc and !pfmemalloc requests. Patch
14 will still protect the system as processes will get throttled if the
pfmemalloc reserves get depleted so performance will not degrade as smoothly.

Assuming this passes testing, I'll add the patch to the series with the
information above included in the changelog.

Thanks Christoph.

-- 
Mel Gorman
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/