From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail172.messagelabs.com (mail172.messagelabs.com [216.82.254.3]) by kanga.kvack.org (Postfix) with ESMTP id 7725F8D003B for ; Tue, 17 May 2011 21:40:32 -0400 (EDT) Received: from kpbe18.cbf.corp.google.com (kpbe18.cbf.corp.google.com [172.25.105.82]) by smtp-out.google.com with ESMTP id p4I1eSab020067 for ; Tue, 17 May 2011 18:40:28 -0700 Received: from qyl38 (qyl38.prod.google.com [10.241.83.230]) by kpbe18.cbf.corp.google.com with ESMTP id p4I1eOEn030238 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Tue, 17 May 2011 18:40:26 -0700 Received: by qyl38 with SMTP id 38so707064qyl.15 for ; Tue, 17 May 2011 18:40:24 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <20110518085258.98f07390.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> Date: Tue, 17 May 2011 18:40:23 -0700 Message-ID: Subject: Re: [PATCH 2/2] memcg: add memory.numastat api for numa statistics From: Ying Han Content-Type: multipart/alternative; boundary=0016360e3f5ce938c004a382f829 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 --0016360e3f5ce938c004a382f829 Content-Type: text/plain; charset=ISO-8859-1 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= ... please confirm? thanks --Ying > Thanks, > -Kame > > --0016360e3f5ce938c004a382f829 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Tue, May 17, 2011 at 4:52 PM, KAMEZAW= A Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> wrote:
On Tue, 17 May 2011 15:25:51 -0700
Ying Han <yinghan@google.com&g= t; wrote:

> 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 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 res= t of counters.
> I might need to change the way get that counter, comments are welcomed= .
>
> Signed-off-by: Ying Han <ying= han@google.com>

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 ?<= br>

Ok, then this is really becoming per-me= mcg numa_maps. Before I go ahead posting the next version, this is somethin= g we are looking for:

total=3D<total pages>=A0N0=3D<node 0 pages>= N1=3D<node 1 pages> ...
anon=3D<total anon pages> N0=3D&= lt;node 0 pages> N1=3D<node 1 pages> ...
file=3D<total file pages> N0=3D<node 0 pages> N1=3D<node = 1 pages> ...

please confirm?

thanks

--Ying
Thanks,
-Kame


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