zyearn

公司做的事就是提供人们想要的东西然后盈利，公司雇员都在打造这个“人们想要的东西”中充当一个角色，微观来看没有意义，更宏观来看可能不可或缺。另外每个人的贡献其实是广义上的贡献，比如清洁人员打扫了办公室，让大家更舒适地工作，从而更有效率，其实也是在帮助公司打造更好的产品（间接地）。

持续出租中

求问申城佳苑早上晚上有班车来回百度吗

zhujiashun2010 at gmail
谢谢~

@jedihy @dcoder thks :)

@qgy18 @Jaylee 如果对 zaver 的编程模型和架构是怎么一步一步构建起来有兴趣，可以看看我的博文： http://lifeofzjs.com/blog/2015/05/16/how-to-write-a-server/，有问题讨论可以在下面留言，我会及时回复:)

@Andiry 谢谢提醒，稍微一想发现，因为多级页表的存在，所以只要复制第一级 table 中 kernel 范围内的指针，就可以实现 kernel page table 共享了。

@adadada 写得很好，瞬间想清楚了很多，谢谢。有一个问题：“ leave kernel paging tables unchanged ” 这个动作是不是一个几乎必须的操作？否则的话需要修改所有进程的 kernel page table 了，开销太大了。

@bengol 感谢回复，特地去看了下 ULK 的相关章节，作者总结了 3 个主要原因：

1. 有些时候连续物理页是必要的，比如 DMA

2. Even if contiguous page frame allocation is not strictly necessary, it offers the big advantage of leaving the kernel paging tables unchanged. What ’ s wrong with modifying the Page Tables? As we know from Chapter 2, frequent Page Table modifications lead to higher average memory access times, because they make the CPU flush the contents of the translation lookaside buffers.

3. 实现 hugepage ，减少了 TLB 表项从而降低 miss rate

其中第二点不是看得很懂，为什么会使 kernel paging tables unchanged ？和你说的 2 是一个意思吗？

@Andiry 感谢回复

请问你的说 2 指的是 hugepage 吗？只有 hugepage 才会减少页表 /页目录项数

另外， xv6 里面的链表里指针指向的 object 都是一个 4k 的页，并且这个指针存在空闲页的开头 8bytes ，所以没有额外的空间复杂度；分配的时间复杂度也是 O(1)，因为直接从链表头拿了。反而 buddy system 的 overhead 比链表高不少，因为它有频繁的合并和分裂内存的操作。所以链表的缺点就是没法分配连续的物理页面了，然后 buddy 就是对它的改进，是这样的吧