Image via Wikipedia
技术爱好者大多都知道 Google 是使用 Linux 的大户，但是一直以来对于他们如何使用 Linux 却知之甚少，甚至内核开发社区对 Google 内部使用的情况也了解不多。LWN 上的这篇 How Google uses Linux 给我们带来了不少信息。
Google 使用 Linux 肯定有很多令人震惊的地方，第一个令人”惊讶”的是他们使用的代码管理工具：Perforce 。代码维护方式看起来也比较落后，当前维护的代码版本远远落后于开源社区内核版本，因为 Google 自己要维护大量的内部特性，每一个大版本发布周期是大约 18 个月，而内部特性的回归也要折腾6个月。因为版本滞后，所以有不少向后移植(Backporting)的工作要做，这个比例大约是 25%，还是不小的。
Google 内部大约有 30 个内核开发人员，而之所以外界很少看到 Google 对 Linux 的 Patch 代码，主要的原因居然是–担心代码不够优雅。我想这应该说的是大实话。我也遇到过很好的开发者对开源软件做了改进之后不愿意把代码贴出来，原因就是担心代码不好看，怕被笑话。
因为应用程序类型之故，对于 Google 来说，完全公平调度器(Completely Fair Scheduler)并不适合，采用了 O(1) 调度器，一般 16-32 核的机器要跑 5000 个线程左右。
Google 倒是喜欢用 Out-of-memory (OOM) killer 特性，这倒是出乎我的意料。Google 对于内存管理方面的改进或许是不小的突破: 通过伪 NUMA 模式来保证不同类型应用对内存的使用。除此之外，有大量的代码用于系统的监控，针对磁盘、网络等子系统或者是针对应用程序性能。
对于计划中的将实现的新特性，在一堆列表中看到了在 I/O 层对于高速 Flash 盘的支持计划。在文末，另一个有趣的技巧是，Google 喜欢把文件系统的元数据 Pin 到内存里以便提高读取响应时间。
或许将来能看到 Google 为 Linux 内核贡献更多代码，那会是一件很有意义的事情。
–EOF–
据说现在不是perforce了，换回svn了，因为google就有svn的开发者，hack起来更方便
代码不优雅实用就行了。可能他们没那么多时间来考虑代码的优雅性了。
谷歌的程序都一只体现出来了，风格就是占用资源少，速度快。
0. git是个必须的目标，不然keep up to main-stream要累死。但是贡献代码比较困难，主要是kernel的review流程非常的长，一个patch改半年是常事。而reviewer/kernel community又比较geeky和picky，这更加重了负担。30多个工程师实在没有太多的时间来做这个。:(
1. CFS将来肯定要进Google自己的kernel – 要不然做系统管理的时候无法解决“一个任务fork出500+个进程，每个偷点CPU”的情况。
2. OOM虽然很heavy，但是也蛮好用 – 如果资源超标，当然不如自动杀了重启。反正在应用层面已经做好了fault-tolerance，死掉个把两个没有啥太大的问题。
3. Fake-NUMA模式将会被渐渐淘汰 – 它的利用率不是那么的高，毕竟目标是轧干服务器的每一滴性能嘛，呵呵。将来可能会转入传统的per-page模式。当然这个模式下可能会带来比较多的sys-usr状态切换，可能是一笔大开销。所以可能要把服务器状态管理等等本来在usr模式下做的东西切进kernel。
4. 其实有个有趣的东西没提到 – 想要获得好性能？关闭swap. :)
我最近在看OpenVZ，这个东西挺有趣，呵呵。