Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752784AbZDGIFJ (ORCPT ); Tue, 7 Apr 2009 04:05:09 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751458AbZDGIEs (ORCPT ); Tue, 7 Apr 2009 04:04:48 -0400 Received: from e28smtp05.in.ibm.com ([59.145.155.5]:49339 "EHLO e28smtp05.in.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751244AbZDGIEp (ORCPT ); Tue, 7 Apr 2009 04:04:45 -0400 Date: Tue, 7 Apr 2009 13:33:55 +0530 From: Balbir Singh To: KAMEZAWA Hiroyuki Cc: "linux-mm@kvack.org" , Andrew Morton , "lizf@cn.fujitsu.com" , Rik van Riel , Bharata B Rao , Dhaval Giani , KOSAKI Motohiro , "linux-kernel@vger.kernel.org" Subject: Re: [RFI] Shared accounting for memory resource controller Message-ID: <20090407080355.GS7082@balbir.in.ibm.com> Reply-To: balbir@linux.vnet.ibm.com References: <20090407063722.GQ7082@balbir.in.ibm.com> <20090407160014.8c545c3c.kamezawa.hiroyu@jp.fujitsu.com> <20090407071825.GR7082@balbir.in.ibm.com> <20090407163331.8e577170.kamezawa.hiroyu@jp.fujitsu.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <20090407163331.8e577170.kamezawa.hiroyu@jp.fujitsu.com> User-Agent: Mutt/1.5.18 (2008-05-17) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 4068 Lines: 121 * KAMEZAWA Hiroyuki [2009-04-07 16:33:31]: > On Tue, 7 Apr 2009 12:48:25 +0530 > Balbir Singh wrote: > > > * KAMEZAWA Hiroyuki [2009-04-07 16:00:14]: > > > > > On Tue, 7 Apr 2009 12:07:22 +0530 > > > Balbir Singh wrote: > > > > > > > Hi, All, > > > > > > > > This is a request for input for the design of shared page accounting for > > > > the memory resource controller, here is what I have so far > > > > > > > > > > In my first impression, I think simple counting is impossible. > > > IOW, "usage count" and "shared or not" is very different problem. > > > > > > Assume a page and its page_cgroup. > > > > > > Case 1) > > > 1. a page is mapped by process-X under group-A > > > 2. its mapped by process-Y in group-B (now, shared and charged under group-A) > > > 3. move process-X to group-B > > > 4. now the page is not shared. > > > > > > > By shared I don't mean only between cgroups, it could be a page shared > > in the same cgroup > > > Hmm, is it good information ? > > Such kind of information can be calucated by > == > rss = 0; > for_each_process_under_cgroup() { > mm = tsk->mm > rss += mm->anon_rss; > } > some_of_all_rss = rss; > > shared_ratio = mem_cgrou->rss *100 / some_of_all_rss. > == > if 100%, all anon memory are not shared. > Why only anon? This seems like a good idea, except when we have a page charged to a cgroup and the task that charged it has migrated, in that case sum_of_all_rss will be 0. > > > > Case 2) > > > swap is an object which can be shared. > > > > > > > Good point, I expect the user to account all cached pages as shared - > > no > Maybe yes if we explain it's so ;) > > ? > > > > > Case 3) > > > 1. a page known as "A" is mapped by process-X under group-A. > > > 2. its mapped by process-Y under group-B(now, shared and charged under group-A) > > > 3. Do copy-on-write by process-X. > > > Now, "A" is mapped only by B but accoutned under group-A. > > > This case is ignored intentionally, now. > > > > Yes, that is the original design > > > > > Do you want to call try_charge() both against group-A and group-B > > > under process-X's page fault ? > > > > > > > No we don't, but copy-on-write is caught at page_rmap_dup() - no? > > > Hmm, if we don't consider group-B, maybe we can. > But I wonder counting is overkill.. > > > > > There will be many many corner case. > > > > > > > > > > Motivation for shared page accounting > > > > ------------------------------------- > > > > 1. Memory cgroup administrators will benefit from the knowledge of how > > > > much of the data is shared, it helps size the groups correctly. > > > > 2. We currently report only the pages brought in by the cgroup, knowledge > > > > of shared data will give a complete picture of the actual usage. > > > > > > > > > > Motivation sounds good. But counting this in generic rmap will have tons of > > > troubles and slow-down. > > > > > > I bet we should prepare a file as > > > /proc//cgroup_maps > > > > > > And show RSS/RSS-owned-by-us per process. Maybe this feature will be able to be > > > implemented in 3 days. > > > > Yes, we can probably do that, but if we have too many processes in one > > cgroup, we'll need to walk across all of them in user space. One other > > alternative I did not mention is to walk the LRU like we walk page > > tables and look at page_mapcount of every page, but that will be > > very slow. > > Can't we make use of information in mm_counters ? (As I shown in above) > (see set/get/add/inc/dec_mm_counters()) > I've seen them, might be a good way to get started, except some corner cases mentioned above. -- 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/