On Thu, May 19, 2011 at 5:24 PM, KAMEZAWA Hiroyuki < kamezawa.hiroyu@jp.fujitsu.com> wrote: > On Thu, 19 May 2011 17:11:49 -0700 > Ying Han wrote: > > > On Thu, May 19, 2011 at 4:51 PM, KAMEZAWA Hiroyuki < > > kamezawa.hiroyu@jp.fujitsu.com> wrote: > > > > > On Thu, 19 May 2011 10:32:40 -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: > > > > > > > > total= N0= N1= ... > > > > file= N0= N1= ... > > > > anon= N0= N1= ... > > > > > > > > $ cat /dev/cgroup/memory/memory.numa_stat > > > > total=246594 N0=18225 N1=72025 N2=26378 N3=129966 > > > > file=221728 N0=15030 N1=60804 N2=23238 N3=122656 > > > > anon=21120 N0=2937 N1=7733 N2=3140 N3=7310 > > > > > > > > > > Hmm ? this doesn't seem consistent....Isn't this log updated ? > > > > > > > Nope. This is the V3 i posted w/ updated testing result. > > > > Did you get this log while applications are running and LRU are changing ? > See N1, 72505 != 60804 + 7733. big error. > Could you clarify why total != file + anon ? > Does the number seems consistent when the system is calm ? > That is because the total includes "unevictable" which is not listed here as "file" and "anon" > > > BTW, I wonder why unevictable is not shown... > mem_cgroup_node_nr_lru_pages() counts unevictable into it because of > for_each_lru(). > > There are 2 ways. > 1. show unevictable > 2. use for_each_evictable_lru(). > > I vote for 1. > Sounds good to me, I can add the "unevictable" following the "file" and "anon" on the next post. Thanks for the review --Ying > > > Thanks, > -Kame > > >