From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail6.bemta7.messagelabs.com (mail6.bemta7.messagelabs.com [216.82.255.55]) by kanga.kvack.org (Postfix) with ESMTP id EC52D8D003B for ; Tue, 17 May 2011 23:05:25 -0400 (EDT) Received: from hpaq1.eem.corp.google.com (hpaq1.eem.corp.google.com [172.25.149.1]) by smtp-out.google.com with ESMTP id p4I35FRJ006569 for ; Tue, 17 May 2011 20:05:15 -0700 Received: from qwh5 (qwh5.prod.google.com [10.241.194.197]) by hpaq1.eem.corp.google.com with ESMTP id p4I358N6000992 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Tue, 17 May 2011 20:05:14 -0700 Received: by qwh5 with SMTP id 5so660187qwh.20 for ; Tue, 17 May 2011 20:05:08 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <20110518110821.20c29c11.kamezawa.hiroyu@jp.fujitsu.com> References: <1305671151-21993-1-git-send-email-yinghan@google.com> <1305671151-21993-2-git-send-email-yinghan@google.com> <20110518085258.98f07390.kamezawa.hiroyu@jp.fujitsu.com> <20110518110821.20c29c11.kamezawa.hiroyu@jp.fujitsu.com> Date: Tue, 17 May 2011 20:05:08 -0700 Message-ID: Subject: Re: [PATCH 2/2] memcg: add memory.numastat api for numa statistics From: Ying Han Content-Type: multipart/alternative; boundary=0016360e3f5cf7abfa04a3842739 Sender: owner-linux-mm@kvack.org List-ID: To: KAMEZAWA Hiroyuki Cc: KOSAKI Motohiro , Minchan Kim , Daisuke Nishimura , Balbir Singh , Tejun Heo , Pavel Emelyanov , 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 --0016360e3f5cf7abfa04a3842739 Content-Type: text/plain; charset=ISO-8859-1 On Tue, May 17, 2011 at 7:08 PM, KAMEZAWA Hiroyuki < kamezawa.hiroyu@jp.fujitsu.com> wrote: > On Tue, 17 May 2011 18:40:23 -0700 > Ying Han wrote: > > > On Tue, May 17, 2011 at 4:52 PM, KAMEZAWA Hiroyuki < > > kamezawa.hiroyu@jp.fujitsu.com> wrote: > > > > > On Tue, 17 May 2011 15:25:51 -0700 > > > Ying Han wrote: > > > > > > > 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: > > > > > > > > N0= N1= ... > > > > > > > > $ cat /dev/cgroup/memory/memory.numa_stat > > > > 292115 N0=36364 N1=166876 N2=39741 N3=49115 > > > > > > > > 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. > > > > > > > > Signed-off-by: Ying Han > > > > > > Hmm, If I'm a user, I want to know file-cache is well balanced or where > > > Anon is > > > allocated from....Can't we have more precice one rather than > > > total(anon+file) ? > > > > > > So, I don't like this patch. Could you show total,anon,file at least ? > > > > > > > Ok, then this is really becoming per-memcg numa_maps. Before I go ahead > > posting the next version, this is something we are looking for: > > > > total= N0= N1= ... > > anon= N0= N1= ... > > file= N0= N1= ... > > > > seems good. > Ok, thank you for clarifying that. I will look into the next post then. --Ying > > THanks, > -Kmae > > --0016360e3f5cf7abfa04a3842739 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Tue, May 17, 2011 at 7:08 PM, KAMEZAW= A Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> wrote:
On Tue, 17 May 2011 18:40:23 -0700
Ying Han <yinghan@google.com> wrote:

> On Tue, May 17, 2011 at 4:52 PM, KAMEZAWA Hiroyuki <
> kamezawa.hiroyu@jp.f= ujitsu.com> wrote:
>
> > On Tue, 17 May 2011 15:25:51 -0700
> > Ying Han <yinghan@google= .com> wrote:
> >
> > > The new API exports numa_maps per-memcg basis. This is a pie= ce of useful
> > > information where it exports per-memcg page distribution acr= oss 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 pages> N0=3D<node 0 pages> N1=3D<node = 1 pages> ...
> > >
> > > $ cat /dev/cgroup/memory/memory.numa_stat
> > > 292115 N0=3D36364 N1=3D166876 N2=3D39741 N3=3D49115
> > >
> > > Note: I noticed <total pages> is not equal to the sum = of the rest of
> > counters.
> > > I might need to change the way get that counter, comments ar= e welcomed.
> > >
> > > Signed-off-by: Ying Han <yinghan@google.com>
> >
> > Hmm, If I'm a user, I want to know file-cache is well balance= d or where
> > Anon is
> > allocated from....Can't we have more precice one rather than<= br> > > total(anon+file) ?
> >
> > So, I don't like this patch. Could you show total,anon,file a= t least ?
> >
>
> Ok, then this is really becoming per-memcg numa_maps. Before I go ahea= d
> posting the next version, this is something we are looking for:
>
> total=3D<total pages> N0=3D<node 0 pages> N1=3D<node 1 = pages> ...
> anon=3D<total anon pages> N0=3D<node 0 pages> N1=3D<nod= e 1 pages> ...
> file=3D<total file pages> N0=3D<node 0 pages> N1=3D<nod= e 1 pages> ...
>

seems good.

Ok, thank you f= or clarifying that. I will look into the next post then.

--Ying=A0

THanks,
-Kmae


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