From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail138.messagelabs.com (mail138.messagelabs.com [216.82.249.35]) by kanga.kvack.org (Postfix) with ESMTP id 409496B0012 for ; Thu, 19 May 2011 11:36:44 -0400 (EDT) Received: from kpbe12.cbf.corp.google.com (kpbe12.cbf.corp.google.com [172.25.105.76]) by smtp-out.google.com with ESMTP id p4JFaf3J023395 for ; Thu, 19 May 2011 08:36:41 -0700 Received: from qyg14 (qyg14.prod.google.com [10.241.82.142]) by kpbe12.cbf.corp.google.com with ESMTP id p4JFaZjs012367 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 19 May 2011 08:36:40 -0700 Received: by qyg14 with SMTP id 14so1604612qyg.19 for ; Thu, 19 May 2011 08:36:35 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <20110519080135.GE3139@balbir.in.ibm.com> References: <1305766511-11469-1-git-send-email-yinghan@google.com> <1305766511-11469-2-git-send-email-yinghan@google.com> <20110519080135.GE3139@balbir.in.ibm.com> Date: Thu, 19 May 2011 08:36:35 -0700 Message-ID: Subject: Re: [PATCH V2 2/2] memcg: add memory.numastat api for numa statistics From: Ying Han Content-Type: multipart/alternative; boundary=0016360e3f5c32db6904a3a2c5be Sender: owner-linux-mm@kvack.org List-ID: To: balbir@linux.vnet.ibm.com Cc: KOSAKI Motohiro , Minchan Kim , Daisuke Nishimura , Tejun Heo , Pavel Emelyanov , KAMEZAWA Hiroyuki , Andrew Morton , Li Zefan , Mel Gorman , Christoph Lameter , Johannes Weiner , Rik van Riel , Hugh Dickins , Michal Hocko , Dave Hansen , Zhu Yanhai , linux-mm@kvack.org --0016360e3f5c32db6904a3a2c5be Content-Type: text/plain; charset=ISO-8859-1 On Thu, May 19, 2011 at 1:01 AM, Balbir Singh wrote: > * Ying Han [2011-05-18 17:55:11]: > > > The new API exports numa_maps per-memcg basis. This is a piece of useful > > information where it exports per-memcg page distribution across real numa > > nodes. > > > > One of the usecase is evaluating application performance by combining > this > > information w/ the cpu allocation to the application. > > > > The output of the memory.numastat tries to follow w/ simiar format of > numa_maps > > like: > > > > total= N0= N1= ... > > file= N0= N1= ... > > anon= N0= N1= ... > > > > That seems like a good idea, so +1 for we need to do this. > Thanks for the +1 :) > > > $ cat /dev/cgroup/memory/memory.numa_stat > > total=317674 N0=101850 N1=72552 N2=30120 N3=113142 > > file=288219 N0=98046 N1=59220 N2=23578 N3=107375 > > anon=25699 N0=3804 N1=10124 N2=6540 N3=5231 > > > > Note: I noticed is not equal to the sum of the rest of > counters. > > I might need to change the way get that counter, comments are welcomed. > > > > Can you see if the total is greater or lesser than the actual value? > Do you have any pages mlocked? > As i replied Daisuke, i think the problem is some pages charged to the memcg might not on the LRU. --Ying > > > change v2..v1: > > 1. add also the file and anon pages on per-node distribution. > > > > Signed-off-by: Ying Han > > --- > > mm/memcontrol.c | 109 > +++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > 1 files changed, 109 insertions(+), 0 deletions(-) > > > -- > Three Cheers, > Balbir > --0016360e3f5c32db6904a3a2c5be Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Thu, May 19, 2011 at 1:01 AM, Balbir = Singh <ba= lbir@linux.vnet.ibm.com> wrote:
* Ying Han <yinghan@google.com= > [2011-05-18 17:55:11]:

> The new API exports numa_maps per-memcg basis. This is a piece of usef= ul
> information where it exports per-memcg page distribution across real n= uma
> nodes.
>
> One of the usecase is evaluating application performance by combining = this
> information w/ the cpu allocation to the application.
>
> The output of the memory.numastat tries to follow w/ simiar format of = numa_maps
> like:
>
> total=3D<total pages> N0=3D<node 0 pages> N1=3D<node 1 = pages> ...
> file=3D<total file pages> N0=3D<node 0 pages> N1=3D<nod= e 1 pages> ...
> anon=3D<total anon pages> N0=3D<node 0 pages> N1=3D<nod= e 1 pages> ...
>

That seems like a good idea, so +1 for we need to do this.

Thanks for the +1 :)
=A0

> $ cat /dev/cgroup/memory/memory.numa_stat
> total=3D317674 N0=3D101850 N1=3D72552 N2=3D30120 N3=3D113142
> file=3D288219 N0=3D98046 N1=3D59220 N2=3D23578 N3=3D107375
> anon=3D25699 N0=3D3804 N1=3D10124 N2=3D6540 N3=3D5231
>
> Note: I noticed <total pages> is not equal to the sum of the res= t of counters.
> I might need to change the way get that counter, comments are welcomed= .
>

Can you see if the total is greater or lesser than the actual value?<= br> Do you have any pages mlocked?

As i rep= lied Daisuke, i think the problem is some pages charged to the memcg might = not on the LRU.

--Ying

> change v2..v1:
> 1. add also the file and anon pages on per-node distribution.
>
> Signed-off-by: Ying Han <ying= han@google.com>
> ---
> =A0mm/memcontrol.c | =A0109 ++++++++++++++++++++++++++++++++++++++++++= +++++++++++++
> =A01 files changed, 109 insertions(+), 0 deletions(-)
>
--
=A0 =A0 =A0 =A0Three Cheers,
=A0 =A0 =A0 =A0Balbir

--0016360e3f5c32db6904a3a2c5be-- -- 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