Message-Id: <20100107174814.ad6820db.kamezawa.hiroyu@jp.fujitsu.com>
Date:	Thu, 7 Jan 2010 17:48:14 +0900
From:	KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>
To:	balbir@...ux.vnet.ibm.com
Cc:	"linux-mm@...ck.org" <linux-mm@...ck.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"nishimura@....nes.nec.co.jp" <nishimura@....nes.nec.co.jp>
Subject: Re: [RFC] Shared page accounting for memory cgroup

On Thu, 7 Jan 2010 14:04:40 +0530
Balbir Singh <balbir@...ux.vnet.ibm.com> wrote:

> * KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com> [2010-01-07 16:36:10]:
> 
> > On Thu, 7 Jan 2010 12:45:54 +0530
> > Balbir Singh <balbir@...ux.vnet.ibm.com> wrote:
> > 
> > > * KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com> [2010-01-06 16:12:11]:
> > > > And piles up costs ? I think cgroup guys should pay attention to fork/exit
> > > > costs more. Now, it gets slower and slower.
> > > > In that point, I never like migrate-at-task-move work in cpuset and memcg.
> > > > 
> > > > My 1st objection to this patch is this "shared" doesn't mean "shared between
> > > > cgroup" but means "shared between processes".
> > > > I think it's of no use and no help to users.
> > > >
> > > 
> > > So what in your opinion would help end users? My concern is that as
> > > we make progress with memcg, we account only for privately used pages
> > > with no hint/data about the real usage (shared within or with other
> > > cgroups). 
> > 
> > The real usage is already shown as
> > 
> >   [root@...extal ref-mmotm]# cat /cgroups/memory.stat
> >   cache 7706181632 
> >   rss 120905728
> >   mapped_file 32239616
> > 
> > This is real. And "sum of rss - rss+mapped" doesn't show anything.
> > 
> > > How do we decide if one cgroup is really heavy?
> > >  
> > 
> > What "heavy" means ? "Hard to page out ?"
> >
> 
> Heavy can also indicate, should we OOM kill in this cgroup or kill the
> entire cgroup? Should we add or remove resources from this cgroup?
> 
That's can be shown by usage...

 
> > Historically, it's caught by pagein/pageout _speed_.
> > "How heavy memory system is ?" can only be measured by "speed".
> 
> Not really... A cgroup might be very large with a large number of its
> pages shared and frequently used. How do we detect if this cgroup
> needs its resources or its taking too many of them.
> 
I don't know. If we have good parameter to know "resource is in short" 
in the kernel, please add to global VM before memcg.
as "/dev/mem_notify" proposed in the past. memcg will use similar logic
which is guaranteed by VM guys.


> > "How pages are shared" doesn't show good hints. I don't hear such parameter
> > is used in production's resource monitoring software.
> > 
> 
> You mean "How many pages are shared" are not good hints, please see my
> justification above. With Virtualization (look at KSM for example),
> shared pages are going to be increasingly important part of the
> accounting.
> 

Considering KSM, your cuounting style is tooo bad.

You should add 

 - MEM_CGROUP_STAT_SHARED_BY_KSM
 - MEM_CGROUP_STAT_FOR_TMPFS/SYSV_IPC_SHMEM

counters to memcg rather than scanning. I can help tests.

I have no objections to have above 2 counters. It's informative.

But, memory reclaim can page-out pages even if pages are shared.
So, "how heavy memcg is" is an independent problem from above coutners.

Thanks,
-Kame



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

Powered by blists - more mailing lists