From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758540Ab0LNJqT (ORCPT ); Tue, 14 Dec 2010 04:46:19 -0500 Received: from gir.skynet.ie ([193.1.99.77]:36521 "EHLO gir.skynet.ie" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1758489Ab0LNJqQ (ORCPT ); Tue, 14 Dec 2010 04:46:16 -0500 Date: Tue, 14 Dec 2010 09:45:56 +0000 From: Mel Gorman To: Andrea Arcangeli Cc: KOSAKI Motohiro , linux-mm@kvack.org, Linus Torvalds , Andrew Morton , linux-kernel@vger.kernel.org, Marcelo Tosatti , Adam Litke , Avi Kivity , Hugh Dickins , Rik van Riel , Dave Hansen , Benjamin Herrenschmidt , Ingo Molnar , Mike Travis , KAMEZAWA Hiroyuki , Christoph Lameter , Chris Wright , bpicco@redhat.com, Balbir Singh , "Michael S. Tsirkin" , Peter Zijlstra , Johannes Weiner , Daisuke Nishimura , Chris Mason , Borislav Petkov Subject: Re: [PATCH 55 of 66] select CONFIG_COMPACTION if TRANSPARENT_HUGEPAGE enabled Message-ID: <20101214094556.GF13914@csn.ul.ie> References: <89a62752012298bb500c.1288798110@v2.random> <20101109151756.BC7B.A69D9226@jp.fujitsu.com> <20101109211145.GB6809@random.random> <20101118162245.GE8135@csn.ul.ie> <20101209190407.GJ19131@random.random> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: <20101209190407.GJ19131@random.random> 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 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< +#ifdef CONFIG_COMPACTION > + (1< +#endif > (1< > 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail143.messagelabs.com (mail143.messagelabs.com [216.82.254.35]) by kanga.kvack.org (Postfix) with ESMTP id 87EC56B008A for ; Tue, 14 Dec 2010 04:46:18 -0500 (EST) Date: Tue, 14 Dec 2010 09:45:56 +0000 From: Mel Gorman Subject: Re: [PATCH 55 of 66] select CONFIG_COMPACTION if TRANSPARENT_HUGEPAGE enabled Message-ID: <20101214094556.GF13914@csn.ul.ie> References: <89a62752012298bb500c.1288798110@v2.random> <20101109151756.BC7B.A69D9226@jp.fujitsu.com> <20101109211145.GB6809@random.random> <20101118162245.GE8135@csn.ul.ie> <20101209190407.GJ19131@random.random> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: <20101209190407.GJ19131@random.random> Sender: owner-linux-mm@kvack.org To: Andrea Arcangeli Cc: KOSAKI Motohiro , linux-mm@kvack.org, Linus Torvalds , Andrew Morton , linux-kernel@vger.kernel.org, Marcelo Tosatti , Adam Litke , Avi Kivity , Hugh Dickins , Rik van Riel , Dave Hansen , Benjamin Herrenschmidt , Ingo Molnar , Mike Travis , KAMEZAWA Hiroyuki , Christoph Lameter , Chris Wright , bpicco@redhat.com, Balbir Singh , "Michael S. Tsirkin" , Peter Zijlstra , Johannes Weiner , Daisuke Nishimura , Chris Mason , Borislav Petkov List-ID: 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< +#ifdef CONFIG_COMPACTION > + (1< +#endif > (1< > 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@kvack.org. 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: email@kvack.org