Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756839Ab0KJQFW (ORCPT ); Wed, 10 Nov 2010 11:05:22 -0500 Received: from mx1.redhat.com ([209.132.183.28]:49504 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756825Ab0KJQFS (ORCPT ); Wed, 10 Nov 2010 11:05:18 -0500 Date: Wed, 10 Nov 2010 17:03:52 +0100 From: Andrea Arcangeli To: Mel Gorman 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: <20101110160352.GJ6809@random.random> References: <20101109121318.BC51.A69D9226@jp.fujitsu.com> <20101109213049.GC6809@random.random> <20101109213855.GM32723@csn.ul.ie> <20101109222240.GH6809@random.random> <20101110142704.GA19679@csn.ul.ie> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20101110142704.GA19679@csn.ul.ie> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2315 Lines: 45 On Wed, Nov 10, 2010 at 02:27:04PM +0000, Mel Gorman wrote: > Agreed. Any performance increase from THP is not likely to offset the > cost of lumpy reclaim. Exactly. Furthermore the improvement will still happen later by polling compaction once every 10 sec with khugepaged (this is also required in case some other guest or application quit releasing tons of ram maybe natively order 9 in the buddy without requiring any further compaction invocation). What the default should be I don't know, but I like a default that fails without causing swap storms. If you want the swap storms and to drop all ptes regardless of their young bits, you should ask explicitly for it I think. Anybody asking for high order allocation and pretending to succeed despite the anti-frag and movable pageblocks migrated with compaction aren't enough to succeed should be able to handle a full graceful failure like THP does by design (or worst case to return error to userland). As far as I can tell tg3 atomic order 2 allocation also provides for a graceful fallback for the same reason (however in new mainline it floods the dmesg with tons of printk, which it didn't used to with older kernels but it's not an actual regression). > Again agreed, I have no problem with lumpy reclaim being pushed aside. > I'm just less keen on it being disabled altogether. I have high hopes > for the series I'm working on that it can be extended slightly to suit > the needs of THP. Great. Well this is also why I disabled it with the smallest possible modification, to avoid stepping on your toes. > Nah, the first thing I did was eliminate being "my fault" :). It would > have surprised me because the patches in isolation worked fine. It > thought the inode changes might have had something to do with it so I > was chasing blind alleys for a while. Hopefully d065bd81 will prove to > be the real problem. Well I wasn't sure if you tested it already on that very workload, the patches weren't from you (even if you were in the signoffs). I mentioned it just in case, glad it's not related :). -- 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/