On Thu, 19 May 2011 17:11:49 -0700 Ying Han <yinghan@xxxxxxxxxx> wrote: > On Thu, May 19, 2011 at 4:51 PM, KAMEZAWA Hiroyuki < > kamezawa.hiroyu@xxxxxxxxxxxxxx> wrote: > > > On Thu, 19 May 2011 10:32:40 -0700 > > Ying Han <yinghan@xxxxxxxxxx> 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=<total pages> N0=<node 0 pages> N1=<node 1 pages> ... > > > file=<total file pages> N0=<node 0 pages> N1=<node 1 pages> ... > > > anon=<total anon pages> N0=<node 0 pages> N1=<node 1 pages> ... > > > > > > $ 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 ? 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. Thanks, -Kame -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxxx 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: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>