内存cgroup的值都是从哪里来的呀
page_counter_charge是增加page_counter的计数，
try_charge函数和mem_cgroup_migrate函数是增加普通进程内存统计的重要方法；
try_charge<---mem_cgroup_try_charge<----
然后在许多缺页中断的路径上会会增加这个计数值
/proc/<pid>/status 中包含的值包括
VmSize中包含一个进程的信息，这个信息怎么和cgroup相关联呢？
－－－－－－－－－－－－２０１７．１０．２９－－－－－－－－－－－－－－－－
// 一个进程的内存包括RSS等信息，这个信息的相关设置位于是在/fs/proc/中，不是ｋｅｒｎｅｌ也不是ｍｍ
hiwater_rss = total_rss = anon + file + shmem;
代码中是如何设置的ＶｍＲＳＳ值的？就是上面的公式，其中
29 anon = get_mm_counter(mm, MM_ANONPAGES); 30 file = get_mm_counter(mm, MM_FILEPAGES); 31 shmem = get_mm_counter(mm, MM_SHMEMPAGES);
其中就包括我一个程序包含的匿名页，那么这几个值都是从哪里来的呢?
在３．１０的内核里，这个值只会包含MM_ANONPAGEＳ和 MM_FILEPAGES两个数值，不包括 MM_SHMEMPAGES
那这俩值都是怎么设置的捏？为什么MM_ANONＰＡＧＥS的值不是实时更新的呀？
就是不是实时更新，也应该是走在前面的我理解，但是现在更新却是极度的慢，我理解是每一次都会有一次缺页的呀。这一个要怎么解释咧?
为什么都是阶跃式的呢？是因为用户态页表一次就映射一个ｐａｇｅ吗？还是说每次会增加一个大页？
为啥一次就出现一次缺页中断：这个值是咋更新的嘛
VmData: 是实际虚拟内存空间增长的值，
并且mmap和malloc的行为也不是一样的，当使用mmap去映射内存时，VmData值一直是增长的; 但是使用malloc去映射内存时，VmData值却是一直不变的，oh my gosh，颠覆三观
mmap是从虚拟地址空间，自高向低分配空间；
malloc是从虚拟地址空间开始，自低向高分配空间；
在调用mmap和munmap的过程中VmData是实时更新的。。。。但是使用malloc就没有这个规律[并且好像其他的值也没有变化]
为啥没有发生缺页呢？
关键函数是：mm_
add_mm_counter_fast
这个函数中并没有及时地把进程的匿名页的数据实时更新到: mm_struct -> mm_rss_stat -->count[NR_MM_COUNTERS] MM_FILEPAGES / MM_ANONPAGES / MM_SWAPIN_PAGES
34e55232e59f7b19050267a05ff1226e5cd122a5
上面这个patch中解释了这个问题，为了解决多线程的问题，每次更新都是在线程内不更新，不去动全局的mm_struct，所以通过mm_struct的统计量，可能会有64*4k=256k的误差。[那这里就哟一个疑问了，如果一个进程创建了1000个线程，每个线程都malloc了32*4k的内存，那么会导致32*1000*4k没有被统计在/proc/VmRSS计数里么 128M都没有被统计在里面？是这样的】