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 <[email protected]> > Cc: David Miller <[email protected]> > Cc: Neil Brown <[email protected]> > Cc: Peter Zijlstra <[email protected]> > Cc: Mike Christie <[email protected]> > Cc: Eric B Munson <[email protected]> > Cc: Eric Dumazet <[email protected]> > Cc: Sebastian Andrzej Siewior <[email protected]> > Cc: Mel Gorman <[email protected]> > Cc: Christoph Lameter <[email protected]> > Cc: Andrew Morton <[email protected]>
Acked-by: David Rientjes <[email protected]> -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
