From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Wed, 8 Nov 2006 09:29:57 +0900 From: KAMEZAWA Hiroyuki Subject: Re: Page allocator: Single Zone optimizations Message-Id: <20061108092957.d9f7fc74.kamezawa.hiroyu@jp.fujitsu.com> In-Reply-To: References: <454A2CE5.6080003@shadowen.org> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org Return-Path: To: Mel Gorman Cc: clameter@sgi.com, apw@shadowen.org, akpm@osdl.org, nickpiggin@yahoo.com.au, linux-mm@kvack.org, a.p.zijlstra@chello.nl List-ID: On Tue, 7 Nov 2006 18:14:31 +0000 (GMT) Mel Gorman wrote: > > Could it be that the only reason that the current approach works is that > > we have not tested with an application that behaves this way? > > > > Probably. The applications I currently test are not mlocking. The tests > currently run workloads that are known to leave the system in a fragmented > state when they complete. In this situation, higher-order allocations fail > even when nothing is running and there are no mlocked() pages on the > standard allocator. > In these days, I've struggled with crashdump from a user to investigate the reason of oom-kill. At last, the reason was most of 2G bytes ZONE_DMA pages were mlocked(). Sigh.... I wonder we can use migration of MOVABLE pages for zone balancing in future. (maybe complicated but...) -Kame -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org