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

持续出租中

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

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 就是对它的改进，是这样的吧

vnc 解决不了吧？用户又不可能去配置路由器，做不了端口映射，所以如果两边都是 symmetric NAT ，只能通过中转服务器来通信或者端口预测，其它类型的 NAT 可以通过打洞的方式来实现直接通信

@JhOOOn fg 是 shell 内置的命令，和 cd 一样，它不是一个可执行程序，有所以理论上一个 shell 连接不关闭，不关机，然后过多久都可以 fg 的。比如你 ssh 到一台主机，只要这个 ssh 连接不断，就可以用 fg

之前用 C++写过一个基于事件的知乎爬虫，底层全部纯手写，不依赖任何库，有兴趣的可以看看... https://github.com/zyearn/zhihuCrawler