On Thu, Dec 09, 2010 at 08:04:07PM +0100, Andrea Arcangeli wrote: > On Thu, Nov 18, 2010 at 04:22:45PM +0000, Mel Gorman wrote: > > Just to confirm - by hang, you mean grinds to a slow pace as opposed to > > coming to a complete stop and having to restart? > > Hmm it's like if you're gigabytes in swap and apps hangs for a while > and system is not really usable and it swaps for most new memory > allocations despite there's plenty of memory free, but it's not a > deadlock of course. > Ok, but it's likely to be kswapd being very aggressive because it's woken up frequently and tries to balance all zones. Once it's not deadlocking entirely, there isn't a more fundamental bug hiding in there somewhere. > BTW, alternatively I could: > > unsigned long transparent_hugepage_flags __read_mostly = > (1<<TRANSPARENT_HUGEPAGE_FLAG)| > +#ifdef CONFIG_COMPACTION > + (1<<TRANSPARENT_HUGEPAGE_DEFRAG_FLAG)| > +#endif > (1<<TRANSPARENT_HUGEPAGE_DEFRAG_KHUGEPAGED_FLAG); > > That would adds GFP_ATOMIC to THP allocation if compaction wasn't > selected, With GFP_NO_KSWAPD, it would stop trashing I suspect the success rate would be extremely low as nothing will be defragmenting memory. > but I think having compaction enabled diminish the risk of > misconfigured kernels leading to unexpected measurements and behavior, > so I feel much safer to keep the select COMPACTION in this patch. > Agreed. -- Mel Gorman Part-time Phd Student Linux Technology Center University of Limerick IBM Dublin Software Lab -- 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 policy in Canada: sign http://dissolvethecrtc.ca/ Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>