On Sat, 25 Aug 2012, Joonsoo Kim wrote:

There is no consideration for pfmemalloc_match() in get_partial(). If we don't
consider that, we can't restrict access to PFMEMALLOC page mostly.

We may encounter following scenario.

Assume there is a request from normal allocation
and there is no objects in per cpu cache and no node partial slab.

In this case, slab_alloc go into slow-path and
new_slab_objects() is invoked. It may return PFMEMALLOC page.
Current user is not allowed to access PFMEMALLOC page,
deactivate_slab() is called (commit 5091b74a95d447e34530e713a8971450a45498b3),
then return object from PFMEMALLOC page.

Next time, when we meet another request from normal allocation,
slab_alloc() go into slow-path and re-go new_slab_objects().
In new_slab_objects(), we invoke get_partial() and we get a partial slab
which we have been deactivated just before, that is, PFMEMALLOC page.
We extract one object from it and re-deactivate.

"deactivate -> re-get in get_partial -> re-deactivate" occures repeatedly.

As a result, we can't restrict access to PFMEMALLOC page and
moreover, it introduce much performance degration to normal allocation
because of deactivation frequently.

Now, we need to consider pfmemalloc_match() in get_partial_node()
It prevent "deactivate -> re-get in get_partial".
Instead, new_slab() is called. It may return !PFMEMALLOC page,
so above situation will be suspended sometime.

Signed-off-by: Joonsoo Kim <redacted>
Cc: David Miller <davem@davemloft.net>
Cc: Neil Brown <redacted>
Cc: Peter Zijlstra <redacted>
Cc: Mike Christie <redacted>
Cc: Eric B Munson <redacted>
Cc: Eric Dumazet <redacted>
Cc: Sebastian Andrzej Siewior <redacted>
Cc: Mel Gorman <mgorman@suse.de>
Cc: Christoph Lameter <redacted>
Cc: Andrew Morton <akpm@linux-foundation.org>

Acked-by: David Rientjes <rientjes@google.com>

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>