On Tue 28-06-11 18:24:30, Kevin Constantine wrote: [...] > [root@tera1133 coda]# cat cgroup.procs > [root@tera1133 coda]# cat memory.usage_in_bytes > 2658271232 > [root@tera1133 coda]# cat memory.use_hierarchy > 0 > [root@tera1133 coda]# cat memory.stat > cache 2658271232 > rss 0 > mapped_file 28672 > pgpgin 376859956 > pgpgout 376210964 > swap 0 > inactive_anon 0 > active_anon 0 > inactive_file 1245843456 > active_file 1412427776 > unevictable 0 > hierarchical_memory_limit 6442450944 > hierarchical_memsw_limit 9223372036854775807 > total_cache 2658271232 > total_rss 0 > total_mapped_file 28672 > total_pgpgin 376859956 > total_pgpgout 376210964 > total_swap 0 > total_inactive_anon 0 > total_active_anon 0 > total_inactive_file 1245843456 > total_active_file 1412427776 > total_unevictable 0 > > I'll start using the values in memory.stat instead.
Yes, this is definitely a better idea because usage_in_bytes doesn't give you precise number anyway (and the more CPUs you have the less fuzzy it might be) because the kernel is trying to be clever and optimize charges so it precharges some memory and it also doing batching of (un)charges in some code paths. To be honest, I do not see any reason to look at memory.usage_in_bytes at all. -- Michal Hocko SUSE Labs SUSE LINUX s.r.o. Lihovarska 1060/12 190 00 Praha 9 Czech Republic ------------------------------------------------------------------------------ All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 _______________________________________________ Libcg-devel mailing list Libcg-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libcg-devel
