Re: [RFI] Shared accounting for memory resource controller

From: Balbir Singh
Date: Wed Apr 08 2009 - 04:50:35 EST


* KAMEZAWA Hiroyuki <kamezawa.hiroyu@xxxxxxxxxxxxxx> [2009-04-08 17:03:41]:

> On Wed, 8 Apr 2009 13:18:09 +0530
> Balbir Singh <balbir@xxxxxxxxxxxxxxxxxx> wrote:
>
> > > > 3. Using the above, we can then try to (using an algorithm you
> > > > proposed), try to do some work for figuring out the shared percentage.
> > > >
> > > This is the point. At last. Why "# of shared pages" is important ?
> > >
> >
> > I posted this in my motivation yesterday. # of shared pages can help
> > plan the system better and the size of the cgroup. A cgroup might have
> > small usage_in_bytes but large number of shared pages. We need a
> > metric that can help figure out the fair usage of the cgroup.
> >
> I don't fully understand but NR_FILE_MAPPED is an information in /proc/meminfo.
> I personally think I want to support information in /proc/meminfo per memcg.
>
> Hmm ? then, if you add a hook, it seems
> == mm/rmap.c
> 689 void page_add_file_rmap(struct page *page)
> 690 {
> 691 if (atomic_inc_and_test(&page->_mapcount))
> 692 __inc_zone_page_state(page, NR_FILE_MAPPED);
> 693 }
> == page_remove_rmap(struct page *page)
> 739 __dec_zone_page_state(page,
> 740 PageAnon(page) ? NR_ANON_PAGES : NR_FILE_MAPPED);
> ==
>
> Is good place to go, maybe.
>
> page->page_cgroup->mem_cgroup-> inc/dec counter ?
>
> Maybe the patch itself will be simple, overhead is unknown..

I thought of the same thing, but then moved to the following

... mem_cgroup_charge_statistics(..) {
if (page_mapcount(page) == 0 && page_is_file_cache(page))
__mem_cgroup_stat_add_safe(cpustat, MEM_CGROUP_STAT_FILE_RSS, val);

But I've not yet tested the end result


--
Balbir
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/