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 ... cheers tobi -- Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland http://it.oetiker.ch tobi@xxxxxxxxxx ++41 62 775 9902 / sb: -9900 -- 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
