Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755330Ab0GGMwo (ORCPT ); Wed, 7 Jul 2010 08:52:44 -0400 Received: from mx1.redhat.com ([209.132.183.28]:24853 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755009Ab0GGMwn (ORCPT ); Wed, 7 Jul 2010 08:52:43 -0400 Message-ID: <4C347862.4020404@redhat.com> Date: Wed, 07 Jul 2010 08:51:46 -0400 From: Rik van Riel User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100430 Fedora/3.0.4-2.fc12 Lightning/1.0b2pre Thunderbird/3.0.4 MIME-Version: 1.0 To: Mel Gorman CC: Christoph Hellwig , Minchan Kim , Johannes Weiner , KOSAKI Motohiro , Andrew Morton , linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, Dave Chinner , Chris Mason , Nick Piggin , KAMEZAWA Hiroyuki , Andrea Arcangeli Subject: Re: [PATCH 12/14] vmscan: Do not writeback pages in direct reclaim References: <20100702125155.69c02f85.akpm@linux-foundation.org> <20100705134949.GC13780@csn.ul.ie> <20100706093529.CCD1.A69D9226@jp.fujitsu.com> <20100706101235.GE13780@csn.ul.ie> <20100706152539.GG13780@csn.ul.ie> <20100706202758.GC18210@cmpxchg.org> <20100707002458.GI13780@csn.ul.ie> <20100707011533.GB3630@infradead.org> <20100707094310.GJ13780@csn.ul.ie> In-Reply-To: <20100707094310.GJ13780@csn.ul.ie> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1194 Lines: 28 On 07/07/2010 05:43 AM, Mel Gorman wrote: > How do you suggest tuning this? The modification I tried was "if N dirty > pages are found during a SWAP_CLUSTER_MAX scan of pages, assume an average > dirtying density of at least that during the time those pages were inserted on > the LRU. In response, ask the flushers to flush 1.5X". This roughly responds > to the conditions it finds as they are encountered and is based on scanning > rates instead of time. It seemed like a reasonable option. Your idea sounds like something we need to have, regardless of whether or not we fix the flusher to flush older inodes first (we probably should do that, too). I believe this for the simple reason that we could have too many dirty pages in one memory zone, while the flusher's dirty threshold is system wide. If we both fix the flusher to flush old inodes first and kick the flusher from the reclaim code, we should be golden. -- All rights reversed -- 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/