OS开发之底层内存管理笔记

　　操作系统从BIOS的int 15h，ax = 0E820h子功能获得64位系统内存表（system memory map）后，需要对可用的内存进行管理，即建立一些数据结构用来记录已用的和空闲的内存，从而为后续的内存的申请使用和释放做准备。

　　考虑到内存的空间有限，为了尽量减小内存管理数据结构所占的额外空间，我决定用IA32架构的小页面大小4KB为粒度管理内存。

　　由于对内存的申请和释放是随机的，所以必须使用链表、树等数据结构而不能使用线性表。又由于对内存的访问十分频繁，所以应该尽量避免在内存管理时使用链表这种遍历时间复杂度为O(n) 的数据结构。出于这样的考虑，我决定选择红黑树作为记录空闲内存的数据结构，红黑树节点中的信息理所当然地可以放在空闲内存当中。

　　为了申请特定大小内存和释放内存时合并邻近空闲内存的方便，我建立了以地址为关键字（key）和以空间大小为关键字的两棵红黑树。在申请特定大小内存时，为了尽量避免碎片，先从大小红黑树中寻找大小刚好匹配的节点，若找不到，再从大小最大的节点分配。这时可能出现两种情况：若需要的大小比最大的节点还大，那么还需要重复上述步骤；若需要的大小比最大的节点小，那么需要分割最大的节点。

　　而在记录已用内存的问题上，我貌似遇到了大麻烦。目前我有两种思路。首先我想到也用红黑树来记录已用内存，但是这些已用内存红黑树节点不能放在申请得到的内存中，因此需要另外申请内存来存放这些节点，这就使情况变得非常复杂。不仅可能陷入存放节点和申请内存的循环中，而且还有管理已用内存红黑树节点这种已用内存的麻烦。

　　然后我想到用位图来管理。但是还是有不小的麻烦：位图存放在哪，如何解决OS可用内存不连续的问题。一个4KB页面的位图最多只能记录128MB的内存的使用情况。对于越来越大的内存，位图的大小很可能超过一段OS可用内存区域的大小，这就会让位图不连续而需要使用链表来组织位图，从而又增加了位图大小的不确定性。

　　若利用分页来将不连续的内存区域映射为连续，则在访问I/O映射内存或显存这种OS不可用内存时就会出现麻烦。