Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755388AbZJ0PgB (ORCPT ); Tue, 27 Oct 2009 11:36:01 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1755502AbZJ0PgA (ORCPT ); Tue, 27 Oct 2009 11:36:00 -0400 Received: from gir.skynet.ie ([193.1.99.77]:49317 "EHLO gir.skynet.ie" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755423AbZJ0Pf7 (ORCPT ); Tue, 27 Oct 2009 11:35:59 -0400 Date: Tue, 27 Oct 2009 15:36:00 +0000 From: Mel Gorman To: Tobias Oetiker Cc: Frans Pop , Jiri Kosina , Sven Geggus , Karol Lewandowski , "Rafael J. Wysocki" , David Miller , Reinette Chatre , Kalle Valo , David Rientjes , KOSAKI Motohiro , Mohamed Abbas , Jens Axboe , "John W. Linville" , Pekka Enberg , Bartlomiej Zolnierkiewicz , Greg Kroah-Hartman , Stephan von Krawczynski , Kernel Testers List , netdev@vger.kernel.org, linux-kernel@vger.kernel.org, "linux-mm@kvack.org" Subject: Re: [PATCH 0/5] Candidate fix for increased number of GFP_ATOMIC failures V2 Message-ID: <20091027153600.GK8900@csn.ul.ie> References: <1256221356-26049-1-git-send-email-mel@csn.ul.ie> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17+20080114 (2008-01-14) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2706 Lines: 70 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 linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/