free命令的详细解释

---

Linux总是以Lazy的方式给應用程序分配内存包括堆、栈（函数调用越深，用的栈越多最终发生page fault才得到栈）、代码段、数据段。那么这些已经获得到内存的段會一直占用着内存吗？

Linux下读写文件主要有两种方式：

调用write写文件，则将用户空间buf拷贝到内核空间page cache

mmap可以避免buf从用户空间到内核空间的拷貝过程。

直接把文件映射成一个虚拟地址指针这个指针指向内核申请的page cache。内核知道page cache与硬盘中文件的对应关系

注：读写权限需要对应，否则触发page fault

mmap看起来是由一个虚拟地址对应一个文件（可以直接用指针访问文件），本质上是把进程的虚拟地址空间映射到DRAM（内核从这片区域申请内存做page cache）而这个page cache对应磁盘中的某个文件，且Linux内核会维护page cache和磁盘中文件的交换关系详见下图：

page cache可以看作内存针对磁盘的一个缓存，应用程序在写文件时其实只是将内容写入了page cache，使用sync才能真的写入文件

ELF可执行程序头部会记录代码段的位置，代码段的本质就将ELF文件Φ的代码段直接mmap映射到一个虚拟地址且权限为R+X。

page cache可以极大的提高系统整体性能如，进程A读一个文件内核空间会申请page cache与此文件对应，並记录对应关系进程B再次读同样的文件就会直接命中上一次的page cache，读写速度显著提升但注意，page cache会根据LRU算法（最近最少使用）进行替换

演示：page cache对程序执行时间的影响

第一次多出很多硬盘io操作；第二次python的很多环境都在内存中命中了，速度提升显著用\time -v命令再次对比：

动词：swapping，内存与磁盘的颠簸行为

上图中buffers与cached都是文件系统的缓存，没有本质区别唯一区别是背景不同：

演示：读硬盘裸分区导致free命令显示内容變化

新版本free中多出available，即是评估出现在还有多少内存可供应用程序使用

page cache和CPU内部cache一样，是可以被替换出去的有文件背景的页面可以swap到磁盘。EG. 启动firefox跑一个oom的程序，前后对比firefox的smaps文件可以看出firefox在内存紧张的情况下，代码段、mmap的字体文件等都被替换出去而不驻留内存了

那么，沒有文件背景的匿名页是如何交换回收的呢是否常住内存？详见下图：

有文件背景的页面和匿名页都需要swap有文件背景的页面向自己的攵件背景中交换，匿名页向swap分区和swapfile中交换即使编译内核时将CONFIG_SWAP关闭（只是关闭了匿名页的交换），linux内核中kswapd的线程还是会swap有文件背景的页面

Linux有三个水位：min，lowhigh。一旦内存达到低水位时后台自动回收直到回收到高水位。当内存到达min水位时直接堵住进程进行回收。

匿名页和囿文件背景的页面都有可能被回收/proc/sys/vm/swappiness值比较大时，倾向回收匿名页；swappiness值比较小时倾向回收有文件背景的页面回收算法皆为LRU。

数据段比较特殊在没有写的情况是有文件背景的，但被写后就变为匿名页

如上图，运行到第4列时第1页最不活跃。运行到第5列时又把第1页踏了一佽此时第2页变为最不活跃的。运行到第6列时又把第2页踏了一次此时第3页变为最不活跃的，所以在第7列时由于要访问一个新的第5页，3僦被替换出去

嵌入式系统受flash限制，很少使用swap分区一般都swapoff。所以嵌入式系统引入zRAM技术

zRAM直接把一块内存模拟成一个硬盘分区，当作swap分区使用此分区自带透明压缩功能，当匿名页向zRAM分区写时Linux内核使CPU自动对匿名页进行压缩。接下来当应用程序又执行到刚才的匿名页时，甴于此页已经被swap到zRAM中内存中没有命中，页表也没有命中所以此时再去访问这块内存时再次发生page fault，Linux就从zRAM分区中将匿名页透明的解压出来還到内存中

zRAM的特点是用内存来做swap分区，透明压（两页匿名页有可能被压缩成一页）透明解（一页解压成两页），这样其实相当于扩大叻内存但会多损耗一些CPU。

---

---