[linux][memory]UKSM内存合并遇到的几个问题

前言： 使用uksm，遇到了几个问题。 分析： 1，RES top命令：

其中VIRT是进程使用的虚拟内存，RES就是要本段要讨论的内容。 分析top的源代码procps:

可见，是从/proc/PID/statm中读取的，即第二项---resident。 继续看kernel代码，linux-4.0.4/fs/proc/task_mmu.c：

可见，resident是file page和anonymous page的和。注意，这里的类型只有MM_FILEPAGES，MM_ANONPAGES，MM_SWAPENTS三种。可见，这个resident的想要表达的就是当前进程在内存中的page的和。 2，uksm下的RES差异 问题反馈在了github：https://github.com/dolohow/uksm/issues/14 大意就是：两个Guest中运行Ubuntu，大约用了1G的RES。再Guest中运行了压测程序，使用2G的内存，一个是写0x00，则用top统计到了1G的RES；一个写0xc5，则用top统计到了3G的RES。 为什么会有这样的差异？ 无论是写0x00，还是写0xc5，都会有2G的内存都是相同的，是可以做merge的。uksm会把相同的2G合并成4K。但是在处理zero page的时候：

uksm在合并zero page的时候，会减少进程的 MM_ANONPAGES计数，所以会看到上述实验现象的差异。 在Github上提了issue，但是uksm的作者觉得这不是bug。 作者也不认为这是bug，但是作者希望无论怎样，二者应该看到相同的RES。kernel无论merge的是zero page还是none zero page，对用户进程都不可见，用户进程不应该看到差异。 3，ksm下的RES 作者在ksm下做了同样的实验，zero page还是none zero pag的情况下，都是3G的RES。 4，RES超过cgroup限制 使用cgroup限制qemu进程的内存使用（by memory.limit_in_bytes）。 限制qemu进程的memory.limit_in_bytes为2G，还是使用上述的例子实验none zero page。会发现，qemu进程的RES是3G。 超！限！了！ 好，别着急，先确认一下cgroup到底使用了多少（by memory.usage_in_bytes）。发现这里其实大约使用了1G，并没有超限。 所以，这里看到的是RES统计和cgroup统计的差异---RES统计的resident page，可是cgroup统计的是cgroup中具体使用的page数量。当uksm/ksm做了merge，实际的page使用会下降（merge page的时候，原来的page做rmap，就会到cgroup做uncharge）。 后记： 关于KSM类型的page统计，zero page的处理 ，不知道会不会成为一个话题。