On Wed, 18 May 2011, Pekka Enberg wrote: > On 5/17/11 12:10 AM, David Rientjes wrote: > > On Fri, 13 May 2011, Mel Gorman wrote: > > > > > To avoid locking and per-cpu overhead, SLUB optimisically uses > > > high-order allocations and falls back to lower allocations if they > > > fail. However, by simply trying to allocate, kswapd is woken up to > > > start reclaiming at that order. On a desktop system, two users report > > > that the system is getting locked up with kswapd using large amounts > > > of CPU. Using SLAB instead of SLUB made this problem go away. > > > > > > This patch prevents kswapd being woken up for high-order allocations. > > > Testing indicated that with this patch applied, the system was much > > > harder to hang and even when it did, it eventually recovered. > > > > > > Signed-off-by: Mel Gorman<mgorman@xxxxxxx> > > Acked-by: David Rientjes<rientjes@xxxxxxxxxx> > > Christoph? I think this patch is sane although the original rationale was to > workaround kswapd problems. I am mostly fine with it. The concerns that I have is if there is a large series of high order allocs then at some point you would want kswapd to be triggered instead of high order allocs constantly failing. Can we have a "trigger once in a while" functionality? -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxxx For more info on Linux MM, see: http://www.linux-mm.org/ . Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/ Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>