Performance

It seems that we still have some race conditions that can lead to strange issues and we may want to discourage this for 6.0-RELEASE.

Alan Cox has committed some fixes for the issue, hope these can be merged back.

Today jianghong has pointed out that ConnectEx found in Windows Socket API has combined the connection and sending of the first block of data together within one system call. I think this is desirable for us too, as this can reduce unnecessary context switches.

FreeBSD has accept_filter(9) mechanism that does similiar thing for accept(2).

(转载自SciScape)

日本的研究团队决定建造世界最快速的超级计算机，夺回失去的世界第一宝座。

在2004年的秋天，IBM的BlueGene/L以每秒钟140*10^12次运算击败了位于日本横滨的Earth Simulator成为世界上最快的超级计算机。现在日本决定投入七亿美金，预计在2011年时建造出可达到每秒10*10^15次运算的超级计算机。

易帜了！易帜了！

经过测试发现，lighttpd的性能要比Apache好。虽然还不是很熟悉，但是这一步迟早要迈出去的。我觉得一个技术人员的生命终结的标志就是开始毫无理由地拒绝尝试新事物。

David Xu’s two recent commits against -HEAD has finally fixed ULE on SMP, PREEMPTION and FULL_PREEMPTION case. Both his and my stress tests has proven that ULE is now rock solid again.

Now we will focus on solving other issues. Please be sure to test our next 6-STABLE snapshot and provide feedback, so we can make a great 6.0-RELEASE!

So time comes that we should consider whether some of our string operations is not optimial and needs some operation. NetBSD seems to have done a lot of good work to make their MD layer better, and we should take these improvements if they are proven.

David O’Brien has pointed out that we should be careful on this, however, since some micro optimizations may hinder performance in a large scenario. With this concern in mind, I will redo some more benchmarks and request for -arch@’s idea before considering commiting the patchset. Currently, the NetBSD implementation of swab(2) is proven to be slower than the GCC generated code by about 25%. I will look into the assembly code generated to see whether I can help to solve this.

Finally we got ULE fixed! After some observation about stability this would definately be MFC’ed to RELENG_[56].

UPDATE: This is proven incomplete. We are still under investigation.

UPDATE: A subsequent commit of David Xu has finally got it fixed.

Will it provide better performance? Interested but not tested.

最近一直在抽空琢磨一些相关的问题。响应时间？抢占？等等。

由于某种原因需要一口气inject大约80万封信，结果中间就不成了。后来发现似乎3000-10000/queue为宜。什么原因呢？