内存cgroup

内存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都没有被统计在里面？是这样的】