Solaris、Linux及FreeBSD三者的内核比较(2)

内存管理和分页

Solaris的进程地址空间由逻辑段segment组成。进程地址中的这些段可以通过pmap访问。Solaris将其内存管理代码和数据结构分为平台无关和平台相关部分(这不跟没说一样嘛。。。)。平台相关部分位于HAT(hardware address translation)层。用vmspace描述进程地址空间，将其划分为逻辑块region。硬件相关部分在pmap(physical map)模块，而vmap 例程处理硬件无关部分和数据结构。Linux使用内存描述符划分进程地址空间，逻辑单位是memory areas。Linux也由pmap来examine 进程地址空间。

Linux将机器相关层从更高层次的机器无关层中划分出来。Solaris和FreeBSD中大多数类似代码比如page fault处理是机器无关的，而Linux处理page fault的代码则非常机器相关--从fault处理开始就是这样了。由此下来的结果是，Linux能很快地完成大多数分页相关代码--因为数据抽象更少。不过，代价是，下层硬件的改变需要大量修改代码--Solaris和FreeBSD则分别把这样的工作堵截在HAT和pmap层搞定。

Segment，region和meory area的分割是：区域的虚拟地址segmetn/region/memory area映射的object/的位置权限map的大小

例如，程序的text(text段，即代码)在一个segmetn/region/memory area中，OS管理地址空间的机制是类似的，不过数据结构名字完全不同。

分页3个都使用了最近最少使用least recently used算法的变种完成页替换。他们都有一个守护daemon进程/线程完成页替换。FreeBSD的是vm_pageout daemon，它周期性地，或者当free的内存不多时，被唤醒。当可用内存低于某个限制时，vm_pageout 运行例程vm_pageout_scan扫描内存并释放一些页面。vm_pageout_scan例程可能需要异步地将更改过的页面写回到磁盘，在释放他们之前。不论由多少颗CPU，只有一个这样的daemon。Solaris的是pageout daemon，它也周期性地运行，处理空闲内存不多的情况。Solaris中的分页限制值在启动时自动校准，这样可以避免该守护进程过渡占用CPU或者向磁盘发出洪水般的换页请求(嗯，flood这么翻正好 ;P )。FreeBSD的daemon在大多数情况下使用的值是固定的--不过也可以调整。Linux的LRU算法可以在运行时动态调整，而且可以有多个kswapd daemon，每CPU最多一个。这3个系统都使用global working set策略，而不是per process working set。FreeBSD有多个页面链表来追踪最近使用页。包括active，inactive，cached和feee页。根据使用情况，页面在这些链表间走来走去。经常访问的页面会在active上。退出的进程的数据页面将被马上放到free上。

如果因为负载原因vm_pageout_scan 来不及扫描全部内存的话，FreeBSD内核可能将整个进程全部换出。如果内存短缺十分严重，vm_pageout_scan 可能会kill系统中最大的进程。Linux也使用不同的页面链表。物理内存被分为(多个)3重zone：一个DMA页面，一个普通页面，一个动态分配内存页面。zone的实现很像由于x86架构限制而很产生的。页面在hot，cold和free链表间移动--机制和FreeBSD的类似。经常用的页面在hot上。可用页面则在cold或者free上。

SUN的大佬使用free链，哈希链，vnode页面链支持自己的LRU实现。后两者大致相当于FreeBSD和Linux的active/hot链--也是FreeBSD和Linux要扫描的链。Solaris要扫描的不是这两个对象，它用two-handed clock算法扫描全部页面(见Solaris Internals 或其他什么地方随你便)。大致方法是，两只手相隔固定举例，前面的手将page的引用位清空以作为标识，如果自此开始没有进程引用这个页，后面的手就释放这个页面(当然如果需要就写回磁盘)。

3个系统在分页时都考虑了NUMA本地性。他们都把IO buffer cache和虚拟内存页面的cache合并到一个系统页cache中。系统页cache用于读写文件已经被mmap了文件，还有应用的text段和data段。

文件系统

3个系统都使用数据抽象层向应用隐藏文件系统实现细节。就是用大家熟悉的open，close，read，write，stat，等等系统调用访问文件，无论下层的文件数据的实现和组织如何。Solaris和FreeBSD把这种机制称为VFS(virtual file system)，基本数据结构是vnode(virtual node)。Solaris和FreeBSD里每个被访问的文件都有一个赋给他们的vnode。除了generic 的文件信息外，vnode还包含到file-system-specific 信息的指针。Linux采用了详细的机制，也叫VFS(virtual file switch)，文件系统无关的数据结构是inode。这个机构和vnode类似(小心：Solaris和FreeBSD也另有自己的inode--是UFS文件系统里file-system-dependent 的数据)。Linux还有两个不同的结构，一个用于文件操作，另一个用于inode操作。Solaris和FreeBSD将他们合并为vnode操作。

VFS允许在系统里实现多种文件系统。这意味着他们相互访问对方的文件系统没问题。只要相关的文件系统例程和数据结构已经被移植到VFS上。所有这3个系统都允许文件系统堆叠stacking。下表列出了每个OS实现的文件系统类型，不是全部哈。

Solaris，FreeBSD和Linux显然都在从对方身上获益。随着Solaris的开源，这种相互促进有望更快。Max个人已经感觉到Linux的变化是最快的。新技术被快速地集成进系统，只是文档和健壮性可能有点落后。Linux有很多--或者有时是看上去有很多--开发者。FreeBSD则大概是(从某种意义上)3个系统中历史最长的。Solaris来自BSD Unix和AT&T Bell实验室Unix的结合，使用了更多数据抽象层，因而一般说来能更简便地支持更多功能。不过，内核中大多数这样的分层都没有文档描述。可能随着代码的开放这一点会有所改善。

至于他们的差别，最大的地方之一是page fault处理了。在Solaris中，发生page fault时，代码是从平台相关的trap handler开始执行的(以大家的智商，这好像不用说了吧。。。)，然后会调用generic的as_fault例程，这个例程判断发生page fault的segment，然后调用segment driver处理page fault。segment driver调用文件系统代码，后者再调用进驱动程序，换入页面。换入完成后，segment driver 调用HAT层来更新页表项。在Linux上，发生page fault后，内核调用的代码在会马上进入平台相关部分，这些处理可能更快，不过可能不太容易扩展和移植(后半段说得太省，不知道作者有没有真的研究过Linux下对应的处理过程)。

内核观察和调试工具对正确理解系统行为有关键意义。在这方面，Solaris有kmdb，mdb和DTrace 。在开源之前，Max就对Solaris做过多年“反向工程”--他发现解决问题的时候使用工具总比阅读代码来得快--我也知道，不过得看什么场合，大家可不要被他误导。Linux嘛，我看作者Max不太熟，所以认为没有太多工具。对FreeBSD，他也认为只是可以用GDB调试内核的dump--Liux也可以。