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 <js1...@gmail.com> > Cc: David Miller <da...@davemloft.net> > Cc: Neil Brown <ne...@suse.de> > Cc: Peter Zijlstra <a.p.zijls...@chello.nl> > Cc: Mike Christie <micha...@cs.wisc.edu> > Cc: Eric B Munson <emun...@mgebm.net> > Cc: Eric Dumazet <eric.duma...@gmail.com> > Cc: Sebastian Andrzej Siewior <sebast...@breakpoint.cc> > Cc: Mel Gorman <mgor...@suse.de> > Cc: Christoph Lameter <c...@linux-foundation.org> > Cc: Andrew Morton <a...@linux-foundation.org>
Acked-by: David Rientjes <rient...@google.com> -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
