dillon

今天起了一个大早，9:00到了位于 1600 Amphitheatre Parkway 的 Google 总部。

手头没有精确的人数统计，不过目测来看，大概有120－150人。看到的第一个见过照片的人是著名的 Cameraman 同学， DragonFly 的 Matthew Dillon 老大！

由于今年是 FreeBSD 计划成立15周年，今年的 MeetBSD ‘08 California 很大程度上是一次 FreeBSD 的活动。

To quote Matthew Dillon:

While I hope to avoid any destabilization, I am fiddling with some pretty hairy code in the VM system so this is a head’s up!I have successfully implemented a basic MAP_VPAGETABLE feature that allows a mmap()’d section of memory to be governed by a virtual page table. Basically the backing store for the mmap()’d space is the‘physical memory’ used to map the space, and the mapping of the space is then governed by a ‘page table’ stored in that physical memory.(It is only physical memory from the point of view of the virtual kernel, not the real kernel of course). The mapping will store a physical page directory offset to tell the VM system where the page table is.

So I finally tried DragonFly on one of our test servers (not my desktop :-). It seems that DragonFly still have some issues with the SATA devices. I am trying to fix it, maybe by porting some good FreeBSD ATAng code.

DragonFly has gave us some good examples that how a user-friendly operating system should, and some different way on designing a MP-capable architecture. Thanks, Matt!

I have ported Matt’s patch to 4-STABLE however Matthew Seaman reports that there is still panic, while different, after the patch and I believe I should port Matt’s VM post-morti diagnostic tools to HEAD.

Matt has committed a critical VM fix and kindly reminded that FreeBSD has also the issue. I have ported the patch here and requested a review by Dr. Alan Cox. I’d like to commit it at once it is approved.

有人一天改了一万一千多行代码。

有人一天改了一万一千多行VFS代码。

有人一天改了一万一千多行FreeBSD VFS代码。

我靠……

Matthew Dillon总是给人惊奇，这是一个你没办法不佩服的人。也许他的一些话让有的人感觉不爽，也许他被一些人误解，但他是Matthew Dillon。

To quote his “I would recommend against per-thread caches. Instead, make the per-cpu caches actually *be* per-cpu (that is, not require a mutex).”

Then, he has pointed out that there is potential problems in FreeBSD’s SLAB allocator which is different from DragonFly’s. (Not too surprisingly, he is again advertising his IPI message approach).

Excerpt from Diary 20040715

很多事情，最终无非是曲终人散，人走茶凉的结果，让人伤心，感觉自己不过是一个过客，不，不仅仅是一个普普通通的过客，还是一个被榨干的，或者，雁过拔毛的过客。

其实过客又如何呢？

这多少让我想起了Theo de Raddt，想起了Matthew Dillon，这两个人也许并不让原先的团队喜欢，至少是意见不同，没办法最后合作下去吧，但他们坚持去做自己的fork。

Matt Dillon has released the RC today. You can download the RC here:

http://www.dragonflybsd.org/main/download.cgi
ftp://ftp.dragonflybsd.org/iso-images/dfly-1.0RC1.iso.gz

Matt said that he will also announce this on FreeBSD list.

自从01年dillon commit之后一直就用着MAXUSERS 0。今天alu提到说MAXUSERS不合适的时候有可能会造成系统负荷能力下降，于是看了代码，发现MAXUSERS是根据内存大小算出来的，32-512之间。另外，实践证明MAXUSERS看来不能设置为2048(起不来)……