On Mon, Oct 26, 2009 at 06:37:36PM +0100, Tobias Oetiker wrote: > Hi Mel, > > I have no done additional tests ... and can report the following > > Thursday Mel Gorman wrote: > > > 1/5 page allocator: Always wake kswapd when restarting an allocation attempt after direct reclaim failed > > 2/5 page allocator: Do not allow interrupts to use ALLOC_HARDER > > > > > > These patches correct problems introduced by me during the 2.6.31-rc1 > > merge window. The patches were not meant to introduce any functional > > changes but two were missed. > > > > If your problem goes away with just these two patches applied, > > please tell me. > > 1+2 do not help > > > Test 3: If you are getting allocation failures, try with the following patch > > > > 3/5 vmscan: Force kswapd to take notice faster when high-order watermarks are being hit > > > > This is a functional change that causes kswapd to notice sooner > > when high-order watermarks have been hit. There have been a number > > of changes in page reclaim since 2.6.30 that might have delayed > > when kswapd kicks in for higher orders > > > > If your problem goes away with these three patches applied, please > > tell me > > 1+2+3 do not help either > > > Test 4: If you are still getting failures, apply the following > > 4/5 page allocator: Pre-emptively wake kswapd when high-order watermarks are hit > > > > This patch is very heavy handed and pre-emptively kicks kswapd when > > watermarks are hit. It should only be necessary if there has been > > significant changes in the timing and density of page allocations > > from an unknown source. Tobias, this patch is largely aimed at you. > > You reported that with patches 3+4 applied that your problems went > > away. I need to know if patch 3 on its own is enough or if both > > are required > > > > If your problem goes away with these four patches applied, please > > tell me > > 3 allone does not help > 3+4 does ... > This is a bit surprising..... Tell me, do you have an Intel IO-MMU on your system by any chance? It should be mentioned in either dmesg or lspci -v (please send the full output of both). If you do have one of these things, I notice they abuse PF_MEMALLOC which would explain why this patch makes a difference to your testing. Thanks -- Mel Gorman Part-time Phd Student Linux Technology Center University of Limerick IBM Dublin Software Lab -- To unsubscribe from this list: send the line "unsubscribe kernel-testers" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
