Documents/kernel team ongoing projects

出自淘宝内核组

跳转到: 导航, 搜索

目录

进行中的工作

目前内核组在针对内部需求进行开发的同时,也与内核社区一同合作开发某些特性。

Ext4不同元数据块I/O数量统计

为了更详细的统计运行时文件系统对不同类型数据块的访问模式,我们在Ext4文件系统和Block层增加了相应的性能计数。这样可以在运行时,根据当时运行在系统上的具体业务,来观察访问文件系统时,不同类型数据被访问的热度。这为我们下一步有针对性的进行优化提供数据支撑。

Ext4 bigalloc

目前Ext4虽然基于extent来管理磁盘上连续的数据块,但是基本的分配单元还是不大于4KB的数据块,这仍然存在磁盘碎片的几率,并且可能被元数据占用的buffer cache仍有可以减少的机会。目前社区正在开发的Ext4 bigalloc特性,可以以超过4KB的尺寸为磁盘块分配的最小单位(譬如64KB),这样可以更加降低文件的磁盘碎片,提高数据在磁盘上的连续性,并进一步降低相关元数据的数量。
这个特性,将会对诸如Hadoop,CDN,TFS这样存储大量数据块文件的应用系统的I/O性能有积极的改进。目前我们和社区一道在测试、复查相关patch。

Ext4 metadata checksum

在2011年LSF(Linus Storage and File System Summit)会议中同Google工程师交流,了解到在Google的集群中,有个别的文件系统报错,很难查出是哪里代码的问题,因此很有可能是元数据在内存或介质中被其它内核缺陷不正确的修改导致。因此与会者商议,为元数据加上校验和,这样如果存在非预期篡改,可以尽早的发现故障。如果等到等到最初的故障持续1-2周后,产生导致内核崩溃或文件系统不一致的严重问题,就很难定位最初的问题所在了。
目前我们在同社区的开发人员一起,进行patch的讨论、审查和测试工作。

Buffered Async I/O

当前Linux内核中的异步I/O机制,是和Direct I/O结合在一起的,也就是说,用户态传递给内核的缓冲区,必须符合Direct I/O的内存对齐要求,并且在I/O返回后,内核中并没有维护相应的page cache,下次访问相同磁盘块时必须再次发送I/O请求。在淘宝内部,有大量异步I/O的工作负载,但是必须在各自应用内部维护用户态缓存机制,无法进行全局共享并且不一定高效。带有page cache支持的buffered Async I/O,将会大大简化编程模型,并对提高I/O性能有积极的帮助。
目前我们正基于社区之前的尝试,结合自己的理解在开发概念原型中。

Transparent Huge Page改进

目前内核的透明大页功能存在如下不足:

  • 当可用的物理内存页面不能直接分配大页框时,当前的物理内存整理(compaction)算法明显影响系统性能,在hadoop上可以看到消耗的系统状态CPU时间为未采用THP内核的一倍以上,影响了hadoop作业处理的效率
  • 目前的THP是可以交换的,并且没有运行时开关来设定是否可以将THP交换到swap分区上去。对于某些对swap敏感的应用,最好能够禁用swap;而对于其他应用,则可以打开swap。

目前我们正在同社区一起,进行概念原型的开发中。

吸收实践Data Center TCP对内部网络的性能优化

Data Center TCP的研究中,不少优化数据中心网络的想法和思路值得借鉴。在借鉴Data Center TCP研究思路的基础上,分析淘宝内部应用在网络上是否存在性能瓶颈,并针对具体问题进行相应的改进。目前还处于问题分析和观察阶段。

将KGTP合并到内核中

KGTP (Kernel GDB Trace Point)是由华人系统软件工程师朱辉(teawater)开发的内核跟踪调试工具,以ko的方式运行而不需要修改内核代码。KGTP功能丰富,安装运行简单,在我们分析系统性能瓶颈的实践中,体现了出色的实用价值。目前我们正在评估和测试KGTP,希望能够和社区合作,尽快将这套工具合并到我们维护的内核中。

个人工具