shmem：

在/proc/meminfo中发现，cached不等于ActiveFile + InActiveFile，我们来看看cache到底都包括啥内存

１）首先肯定包含activeFile 和　inactiveFile

 58     cached = global_node_page_state(NR_FILE_PAGES) -
 59             total_swapcache_pages() - i.bufferram;
 所以在/proc/meminfo中的cache的内存就是activeFile+inactiveFile+shmMem-bufferRam

Memory　availbale中的内存是啥？

那么所有的NR_FILE_PAGEa是啥子呢？

＝

所以ｃａｃｈｅ的计算公式是：nr_file_pages是怎么计算出来的，是所有的问题集

---------------------------------------

内核中的 tmpfs 就是 share memory

内核中的tmpfs就是share memory

是一个虚拟的文件系统，都是在一个ｓｈａｒｅ　ｍｅｍｏｒｙ的文件系统中存储的，所以所有对共享内存的申请，将来都是落到ｔｍｐｆｓ中去的，所以我们看下集中典型的内存的申请的方式：shmget和mmap的方式是不是都是从ｔｍｐｆｓ文件系统中去分配ｉｎｏｄｅ，并且这种ｉｎｏｄｅ是不能被ｆｌｕｓｈ掉的，所以有三种方式来处理，shget/mmap/write /dev/shm

那么我通过mmap的方式申请内存

方式二：

 ptr = mmap(NULL, 4096000, PROT_READ | PROT_WRITE, MAP_ANONYMOUS | MAP_SHARED, -1, 0);

这种方式的内存既会统计在ｓｈａｒｅ　ｍｅｍｏｒｙ中，也会统计在ｐａｇｅ　ｃａｃｈｅ里，所以说到底，这里应该是统计到文件系统中了；

方式三：

直接向/dev/shm中写数据，ｓｈａｒｅ　ｍｅｍｏｒｙ确实是增加了，也被统计到ｐａｇｅ　ｃａｃｈｅ里，匪夷所思啊

这种也是从ｓｈａｒｅ　ｍｅｍｏｒｙ里分配的内存么？刚开始也是没有内存吧？然后真正写的时候发生缺页中断

方式四：

使用shmat之后，内存的分配

为什么释放之后，shm还没有被释放掉呢，但是

mmap发生缺页中断之后，这个page会添加到tmp的page cache里吗？

虽然在ｓｈｍ中的内存是在ｔｍｐｆｓ中管理的，但是，这些内存是算到shared里的，这种是共享

在/proc/meminfo中存储的

ret = vma->vm_ops->fault(vma, &vmf);

每一段vma也都会注册一套函数，这里就是一个内存段发生缺页时会调用的函数，Call Trace:
 [<ffffffff8114668b>] shmem_getpage_gfp+0x41b/0xab0
 [<ffffffff81146de9>] shmem_fault+0x69/0x1a0
 [<ffffffff811b790c>] ? __mark_inode_dirty+0x32c/0x390
 [<ffffffff8130a8fe>] shm_fault+0x1e/0x20
 [<ffffffff81158e91>] __do_fault+0x71/0xe0
 [<ffffffff8115dc09>] handle_mm_fault+0x3b9/0xde0
 [<ffffffff8116417d>] ? do_mmap+0x44d/0x500
 [<ffffffff81046eb4>] __do_page_fault+0x244/0x4e0
 [<ffffffff8104715c>] do_page_fault+0xc/0x10
 [<ffffffff8187f362>] page_fault+0x22/0x30
shm_fault: syslogd

真正的匿名页是不会走到这里的真正的匿名页不是在虚拟的文件系统中管理的，而是直接管理，二者是在那个地方分的叉的呢？handle_pte_fault，在这里分为了两个流向了不同的防线1）do_anonymous_page2)  do_fault -->  __do_fault所以这里怎么判断一块区域到底是不是匿名页呢？是通过vma_is_aonnymous的：!vma->vm_ops，只有这种page才需要特殊的映射的方法

shm_mem_fault->shmem_getpage_gfp ---> shmem_add_to_page_cache
shm_mem_fault是大家都要经历过的一环