From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail202.messagelabs.com (mail202.messagelabs.com [216.82.254.227]) by kanga.kvack.org (Postfix) with ESMTP id 076536B003D for ; Tue, 17 Mar 2009 02:22:23 -0400 (EDT) Received: from d23relay02.au.ibm.com (d23relay02.au.ibm.com [202.81.31.244]) by e23smtp07.au.ibm.com (8.13.1/8.13.1) with ESMTP id n2H6MH3O002422 for ; Tue, 17 Mar 2009 17:22:17 +1100 Received: from d23av04.au.ibm.com (d23av04.au.ibm.com [9.190.235.139]) by d23relay02.au.ibm.com (8.13.8/8.13.8/NCO v9.2) with ESMTP id n2H6MW5a815254 for ; Tue, 17 Mar 2009 17:22:34 +1100 Received: from d23av04.au.ibm.com (loopback [127.0.0.1]) by d23av04.au.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n2H6MEFh009073 for ; Tue, 17 Mar 2009 17:22:14 +1100 Date: Tue, 17 Mar 2009 11:52:05 +0530 From: Balbir Singh Subject: Re: [PATCH 4/4] Memory controller soft limit reclaim on contention (v6) Message-ID: <20090317062205.GN16897@balbir.in.ibm.com> Reply-To: balbir@linux.vnet.ibm.com References: <20090316113853.GA16897@balbir.in.ibm.com> <969730ee419be9fbe4aca3ec3249650e.squirrel@webmail-b.css.fujitsu.com> <20090316121915.GB16897@balbir.in.ibm.com> <20090317124740.d8356d01.kamezawa.hiroyu@jp.fujitsu.com> <20090317044016.GG16897@balbir.in.ibm.com> <20090317134727.62efc14e.kamezawa.hiroyu@jp.fujitsu.com> <20090317045850.GJ16897@balbir.in.ibm.com> <20090317141714.0899baec.kamezawa.hiroyu@jp.fujitsu.com> <20090317055506.GM16897@balbir.in.ibm.com> <20090317150058.5b8a96b9.kamezawa.hiroyu@jp.fujitsu.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <20090317150058.5b8a96b9.kamezawa.hiroyu@jp.fujitsu.com> Sender: owner-linux-mm@kvack.org To: KAMEZAWA Hiroyuki Cc: linux-mm@kvack.org, YAMAMOTO Takashi , lizf@cn.fujitsu.com, KOSAKI Motohiro , Rik van Riel , Andrew Morton List-ID: * KAMEZAWA Hiroyuki [2009-03-17 15:00:58]: > On Tue, 17 Mar 2009 11:25:06 +0530 > Balbir Singh wrote: > > > * KAMEZAWA Hiroyuki [2009-03-17 14:17:14]: > > > > That is not true..we don't track them to default cgroup unless > > > > memory.use_hiearchy is enabled in the root cgroup. > > > What I want to say is "the task which is not attached to user's cgroup is > > > also under defaut cgroup, so we don't need additional hook" > > > Not talking about hierarchy. > > > > > > > Since all the user pages are tracked in one or the other cgroup, the > > total accounting is equal to total_lru_pages across all zones/nodes. > > Your suggestion boils down to if total_lru_pages reaches a threshold, > > do soft limit reclaim, instead of doing reclaim when there is > > contention.. right? > > > Yes. > May I suggest that we first do the reclaim on contention and then later on enhance it to add sysctl vm.soft_limit_ratio. I am not proposing the soft limit patches for 2.6.30, but I would like to get them in -mm for wider testing. If in that process the sysctl seems more useful and applicable, we can consider adding it. Adding it right now makes the reclaim logic more complex, having to check if we hit the vm ratio quite often. Do you agree? > > > > It's not necessary. for example, reading vmstat doesn't need global lock. > > > > > > > It uses atomic values for accounting. > > > Ah, my point is that "when it comes to usage of global LRU, > accounting pages is already done somewhere. we can reuse it." > Not means "add some new counter" > OK. -- Balbir -- 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/ . Don't email: email@kvack.org