From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from psmtp.com (na3sys010amx136.postini.com [74.125.245.136]) by kanga.kvack.org (Postfix) with SMTP id 612616B004F for ; Wed, 18 Jan 2012 21:26:47 -0500 (EST) Received: from m3.gw.fujitsu.co.jp (unknown [10.0.50.73]) by fgwmail5.fujitsu.co.jp (Postfix) with ESMTP id DD52E3EE081 for ; Thu, 19 Jan 2012 11:26:45 +0900 (JST) Received: from smail (m3 [127.0.0.1]) by outgoing.m3.gw.fujitsu.co.jp (Postfix) with ESMTP id C1E3345DEAD for ; Thu, 19 Jan 2012 11:26:45 +0900 (JST) Received: from s3.gw.fujitsu.co.jp (s3.gw.fujitsu.co.jp [10.0.50.93]) by m3.gw.fujitsu.co.jp (Postfix) with ESMTP id A52D345DEA6 for ; Thu, 19 Jan 2012 11:26:45 +0900 (JST) Received: from s3.gw.fujitsu.co.jp (localhost.localdomain [127.0.0.1]) by s3.gw.fujitsu.co.jp (Postfix) with ESMTP id 973511DB803F for ; Thu, 19 Jan 2012 11:26:45 +0900 (JST) Received: from m106.s.css.fujitsu.com (m106.s.css.fujitsu.com [10.240.81.146]) by s3.gw.fujitsu.co.jp (Postfix) with ESMTP id 4B3601DB8040 for ; Thu, 19 Jan 2012 11:26:45 +0900 (JST) Date: Thu, 19 Jan 2012 11:25:28 +0900 From: KAMEZAWA Hiroyuki Subject: Re: [RFC 2/3] vmscan hook Message-Id: <20120119112528.eda78467.kamezawa.hiroyu@jp.fujitsu.com> In-Reply-To: <4F16D46D.5080000@redhat.com> References: <1326788038-29141-1-git-send-email-minchan@kernel.org> <1326788038-29141-3-git-send-email-minchan@kernel.org> <20120117173932.1c058ba4.kamezawa.hiroyu@jp.fujitsu.com> <20120117091356.GA29736@barrios-desktop.redhat.com> <20120117190512.047d3a03.kamezawa.hiroyu@jp.fujitsu.com> <20120117230801.GA903@barrios-desktop.redhat.com> <20120118091824.0bde46f7.kamezawa.hiroyu@jp.fujitsu.com> <4F16D46D.5080000@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Rik van Riel Cc: Minchan Kim , linux-mm , LKML , leonid.moiseichuk@nokia.com, penberg@kernel.org, mel@csn.ul.ie, rientjes@google.com, KOSAKI Motohiro , Johannes Weiner , Marcelo Tosatti , Andrew Morton , Ronen Hod On Wed, 18 Jan 2012 09:17:17 -0500 Rik van Riel wrote: > On 01/17/2012 07:18 PM, KAMEZAWA Hiroyuki wrote: > > On Wed, 18 Jan 2012 08:08:01 +0900 > > Minchan Kim wrote: > > > >>>>> 2. can't we measure page-in/page-out distance by recording something ? > >>>> > >>>> I can't understand your point. What's relation does it with swapout prevent? > >>>> > >>> > >>> If distance between pageout -> pagein is short, it means thrashing. > >>> For example, recoding the timestamp when the page(mapping, index) was > >>> paged-out, and check it at page-in. > >> > >> Our goal is prevent swapout. When we found thrashing, it's too late. > > > > If you want to prevent swap-out, don't swapon any. That's all. > > Then, you can check the number of FILE_CACHE and have threshold. > > I think you are getting hung up on a word here. > > As I understand it, the goal is to push out the point where > we start doing heavier swap IO, allowing us to overcommit > memory more heavily before things start really slowing down. > Yes. Hmm, considering that the issue is slow down, time values as - 'cpu time used for memory reclaim' - 'latency of page allocation' - 'application execution speed' ? may be a better score to see rather than just seeing lru's stat. Thanks, -Kame -- 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 internet charges in Canada: sign http://stopthemeter.ca/ Don't email: email@kvack.org