From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755021Ab0KIVjO (ORCPT ); Tue, 9 Nov 2010 16:39:14 -0500 Received: from gir.skynet.ie ([193.1.99.77]:50832 "EHLO gir.skynet.ie" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753483Ab0KIVjK (ORCPT ); Tue, 9 Nov 2010 16:39:10 -0500 Date: Tue, 9 Nov 2010 21:38:55 +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 01 of 66] disable lumpy when compaction is enabled Message-ID: <20101109213855.GM32723@csn.ul.ie> References: <20101109121318.BC51.A69D9226@jp.fujitsu.com> <20101109213049.GC6809@random.random> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: <20101109213049.GC6809@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 Tue, Nov 09, 2010 at 10:30:49PM +0100, Andrea Arcangeli wrote: > On Tue, Nov 09, 2010 at 12:18:49PM +0900, KOSAKI Motohiro wrote: > > I'm talking very personal thing now. I'm usually testing both feature. > > Then, runtime switching makes my happy :-) > > However I don't know what are you and Mel talking and agree about this. > > So, If many developer prefer this approach, I don't oppose anymore. > > Mel seem to still prefer I allow lumpy for hugetlbfs with a > __GFP_LUMPY specified only for hugetlbfs. But he measured compaction > is more reliable than lumpy at creating hugepages so he seems to be ok > with this too. > Specifically, I measured that lumpy in combination with compaction is more reliable and lower latency but that's not the same as deleting it. That said, lumpy does hurt the system a lot. I'm prototyping a series at the moment that pushes lumpy reclaim to the side and for the majority of cases replaces it with "lumpy compaction". I'd hoping this will be sufficient for THP and alleviate the need to delete it entirely - at least until we are 100% sure that compaction can replace it in all cases. Unfortunately, in the process of testing it today I also found out that 2.6.37-rc1 had regressed severely in terms of huge page allocations so I'm side-tracked trying to chase that down. My initial theories for the regression have shown up nothing so I'm currently preparing to do a bisection. This will take a long time though because the test is very slow :( I can still post the series as an RFC if you like to show what direction I'm thinking of but at the moment, I'm unable to test it until I pin the regression down. > > But, I bet almost all distro choose CONFIG_COMPACTION=y. then, lumpy code > > will become nearly dead code. So, I like just kill than dead code. however > > it is also only my preference. ;) > > Killing dead code is my preference too indeed. But then it's fine with > me to delete it only later. In short this is least intrusive > modification I could make to the VM that wouldn't than hang the system > when THP is selected because all pte young bits are ignored for >50% > of page reclaim invocations like lumpy requires. > -- 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 mail172.messagelabs.com (mail172.messagelabs.com [216.82.254.3]) by kanga.kvack.org (Postfix) with ESMTP id B57576B004A for ; Tue, 9 Nov 2010 16:39:13 -0500 (EST) Date: Tue, 9 Nov 2010 21:38:55 +0000 From: Mel Gorman Subject: Re: [PATCH 01 of 66] disable lumpy when compaction is enabled Message-ID: <20101109213855.GM32723@csn.ul.ie> References: <20101109121318.BC51.A69D9226@jp.fujitsu.com> <20101109213049.GC6809@random.random> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: <20101109213049.GC6809@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 Tue, Nov 09, 2010 at 10:30:49PM +0100, Andrea Arcangeli wrote: > On Tue, Nov 09, 2010 at 12:18:49PM +0900, KOSAKI Motohiro wrote: > > I'm talking very personal thing now. I'm usually testing both feature. > > Then, runtime switching makes my happy :-) > > However I don't know what are you and Mel talking and agree about this. > > So, If many developer prefer this approach, I don't oppose anymore. > > Mel seem to still prefer I allow lumpy for hugetlbfs with a > __GFP_LUMPY specified only for hugetlbfs. But he measured compaction > is more reliable than lumpy at creating hugepages so he seems to be ok > with this too. > Specifically, I measured that lumpy in combination with compaction is more reliable and lower latency but that's not the same as deleting it. That said, lumpy does hurt the system a lot. I'm prototyping a series at the moment that pushes lumpy reclaim to the side and for the majority of cases replaces it with "lumpy compaction". I'd hoping this will be sufficient for THP and alleviate the need to delete it entirely - at least until we are 100% sure that compaction can replace it in all cases. Unfortunately, in the process of testing it today I also found out that 2.6.37-rc1 had regressed severely in terms of huge page allocations so I'm side-tracked trying to chase that down. My initial theories for the regression have shown up nothing so I'm currently preparing to do a bisection. This will take a long time though because the test is very slow :( I can still post the series as an RFC if you like to show what direction I'm thinking of but at the moment, I'm unable to test it until I pin the regression down. > > But, I bet almost all distro choose CONFIG_COMPACTION=y. then, lumpy code > > will become nearly dead code. So, I like just kill than dead code. however > > it is also only my preference. ;) > > Killing dead code is my preference too indeed. But then it's fine with > me to delete it only later. In short this is least intrusive > modification I could make to the VM that wouldn't than hang the system > when THP is selected because all pte young bits are ignored for >50% > of page reclaim invocations like lumpy requires. > -- 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