On Tue, May 10, 2011 at 09:01:04AM -0500, James Bottomley wrote:

On Tue, 2011-05-10 at 11:21 +0100, Mel Gorman wrote:

quoted

I really would like to hear if the fix makes a big difference or
if we need to consider forcing SLUB high-order allocations bailing
at the first sign of trouble (e.g. by masking out __GFP_WAIT in
allocate_slab). Even with the fix applied, kswapd might be waking up
less but processes will still be getting stalled in direct compaction
and direct reclaim so it would still be jittery.

"the fix" being this

https://lkml.org/lkml/2011/3/5/121

Drop this for the moment. It was a long shot at best and there is little
evidence the problem is in this area.

I'm attaching two patches. The first is the NO_KSWAPD one to stop
kswapd being woken up by SLUB using speculative high-orders. The second
one is more drastic and prevents slub entering direct reclaim or
compaction. It applies on top of patch 1. These are both untested and
afraid are a bit rushed as well :(

-- 
Mel Gorman
SUSE Labs