Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752859Ab1BRGSJ (ORCPT ); Fri, 18 Feb 2011 01:18:09 -0500 Received: from e28smtp03.in.ibm.com ([122.248.162.3]:47021 "EHLO e28smtp03.in.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751759Ab1BRGSI (ORCPT ); Fri, 18 Feb 2011 01:18:08 -0500 Date: Fri, 18 Feb 2011 11:25:05 +0530 From: Balbir Singh To: Minchan Kim Cc: Andrew Morton , linux-mm , LKML , Steven Barrett , Ben Gamari , Peter Zijlstra , Rik van Riel , Mel Gorman , KOSAKI Motohiro , Wu Fengguang , Johannes Weiner , Nick Piggin , Andrea Arcangeli , KAMEZAWA Hiroyuki Subject: Re: [PATCH v5 0/4] fadvise(DONTNEED) support Message-ID: <20110218055505.GA2648@balbir.in.ibm.com> Reply-To: balbir@linux.vnet.ibm.com References: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 4087 Lines: 93 * MinChan Kim [2011-02-18 00:08:18]: > Sorry for my laziness. It's time to repost with some test result. > > Recently, there was a reported problem about thrashing. > (http://marc.info/?l=rsync&m=128885034930933&w=2) > It happens by backup workloads(ex, nightly rsync). > That's because the workload makes just use-once pages > and touches pages twice. It promotes the page into > active list so that it results in working set page eviction. > So app developer want to support POSIX_FADV_NOREUSE but other OSes include linux > don't support it. (http://marc.info/?l=linux-mm&m=128928979512086&w=2) > > By other approach, app developers use POSIX_FADV_DONTNEED. > But it has a problem. If kernel meets page is going on writing > during invalidate_mapping_pages, it can't work. > It makes application programmer to use it hard since they always > consider sync data before calling fadivse(..POSIX_FADV_DONTNEED) to > make sure the pages couldn't be discardable. At last, they can't use > deferred write of kernel so see performance loss. > (http://insights.oetiker.ch/linux/fadvise.html) > > In fact, invalidation is very big hint to reclaimer. > It means we don't use the page any more. So the idea in this series is that > let's move invalidated pages but not-freed page until into inactive list. > It can help relcaim efficiency very much so that it can prevent > eviction working set. > > My exeperiment is folowing as. > > Test Environment : > DRAM : 2G, CPU : Intel(R) Core(TM)2 CPU > Rsync backup directory size : 16G > > rsync version is 3.0.7. > rsync patch is Ben's fadivse. > The stress scenario do following jobs with parallel. > > 1. git clone linux-2.6 > 1. make all -j4 linux-mmotm > 3. rsync src dst > > nrns : no-patched rsync + no stress > prns : patched rsync + no stress > nrs : no-patched rsync + stress > prs : patched rsync + stress > > For profiling, I add some vmstat. > pginvalidate : the total number of pages which are moved by this patch. > pgreclaim : the number of pages which are moved at inactive's tail by PG_reclaim of pginvalidate > > NRNS PRNS NRS PRS > Elapsed time 36:01.49 37:13.58 01:23:24 01:21:45 > nr_vmscan_write 184 1 296 509 > pgactivate 76559 84714 445214 463143 > pgdeactivate 19360 40184 74302 91423 > pginvalidate 0 2240333 0 1769147 > pgreclaim 0 1849651 0 1650796 > pgfault 406208 421860 72485217 70334416 > pgmajfault 212 334 5149 3688 > pgsteal_dma 0 0 0 0 > pgsteal_normal 2645174 1545116 2521098 1578651 > pgsteal_high 5162080 2562269 6074720 3137294 > pgsteal_movable 0 0 0 0 > pgscan_kswapd_dma 0 0 0 0 > pgscan_kswapd_normal 2641732 1545374 2499894 1557882 > pgscan_kswapd_high 5143794 2567981 5999585 3051150 > pgscan_kswapd_movable 0 0 0 0 > pgscan_direct_dma 0 0 0 0 > pgscan_direct_normal 3643 0 21613 21238 > pgscan_direct_high 20174 1783 76980 87848 > pgscan_direct_movable 0 0 0 0 > pginodesteal 130 1029 3510 24100 > slabs_scanned 1421824 1648128 1870720 1880320 > kswapd_steal 7785153 4105620 8498332 4608372 > kswapd_inodesteal 189432 474052 342835 472503 > pageoutrun 100687 52282 145712 70946 > allocstall 22 1 149 163 > pgrotated 0 2231408 2932 1765393 > unevictable_pgs_scanned 0 0 0 0 > The results do look impressive -- Three Cheers, Balbir -- 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/