Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754158Ab0KXSBj (ORCPT ); Wed, 24 Nov 2010 13:01:39 -0500 Received: from gir.skynet.ie ([193.1.99.77]:50218 "EHLO gir.skynet.ie" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753162Ab0KXSBi (ORCPT ); Wed, 24 Nov 2010 13:01:38 -0500 Date: Wed, 24 Nov 2010 18:01:22 +0000 From: Mel Gorman To: Minchan Kim Cc: Andrew Morton , Ben Gamari , linux-mm , LKML , Peter Zijlstra , Rik van Riel , KOSAKI Motohiro , Johannes Weiner , Nick Piggin Subject: Re: [RFC 1/2] deactive invalidated pages Message-ID: <20101124180122.GC19571@csn.ul.ie> References: <20101122141449.9de58a2c.akpm@linux-foundation.org> <20101122210132.be9962c7.akpm@linux-foundation.org> <20101123093859.GE19571@csn.ul.ie> <87k4k49jii.fsf@gmail.com> <20101123145856.GQ19571@csn.ul.ie> <20101123123535.438e9750.akpm@linux-foundation.org> <20101123221049.GR19571@csn.ul.ie> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: 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 Content-Length: 2479 Lines: 50 On Wed, Nov 24, 2010 at 08:45:20AM +0900, Minchan Kim wrote: > > > >> I just don't see any argument for moving the page to the head of the > >> inactive LRU as a matter of policy. ?We can park it there because we > >> can't think of anythnig else to do with it, but it's the wrong place > >> for it. > >> > > > > Is there a better alternative? One thing that springs to mind is that we are > > not exactly tracking very well what effect these policy changes have. The > > analysis scripts I have do a reasonable job on tracking reclaim activity > > (although only as part of the mmtests tarball, I should split them out as > > a standalone tool) but not the impact - namely minor and major faults. I > > should sort that out so we can put better reclaim analysis in place. > > It can help very much. :) > > Also, I need time since I am so busy. > No worries, I had a framework in place that made it easy enough to collect. The necessary information is available in /proc/vmstat in this case so a tester just needs to record vmstat before and after the target workload runs. For the reclaim/compaction series, a partial run of the series and the subsequent report looks like; proc vmstat: Faults traceonly reclaimcompact obeysync Major Faults 84102 6724 7298 Minor Faults 139704394 138778777 138777304 Page ins 4966564 3621280 3569508 Page outs 11283328 7980576 7959352 Swap ins 85800 5647 7062 Swap outs 828488 8799 10565 Series acted as expected - major faults were reduced. Minor faults on on the high side which I didn't analyse further. Main thing that it's possible to collect the information on what reclaim is doing and how it affects processes. I don't have anything in place to evaluate this series unfortunately as I haven't automated a workload that depends on the behaviour of fadvise. -- Mel Gorman Part-time Phd Student Linux Technology Center University of Limerick IBM Dublin Software Lab -- 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/