LWN回顾: facebook利用transparent huge page来优化代码执行性能

点击上方蓝色字关注我们~

Transparent huge pages for filesystems

By Jake Edge
May 22, 2019

---

LSFMM

继续2019 Linux Storage, Filesystem, and Memory-Management Summit (LSFMM)会议记录。Liu Song在会场里提出一个问题，关于如何让文件系统能真正支持transparement huge pages (THPs)。大家都知道文件系统支持THPs很难，那么如何开始第一步？Liu Song在Facebook工作，他们很需要在file page cache里面支持THPs。THPs可以减少page数量，从而减少TLB miss（Translation lookaside buffer miss，指MMU地址翻译没法利用TLB快速查询到结果，需要走完整的MMU walk路径，耗时较长），也就会有更好的performance。Facebook希望把常用的函数都放到huge page里面，从而减少相关指令导致的TLB miss。Facebook先利用Binary Optimization and Layout Tool (BOLT) 来采集他们的代码的运行情况，了解最常用函数是哪些。然后把这些函数归集到一个8MB的memory空间，塞到最终生成的可执行程序里去。

在程序运行的时候，它会在内存里创建一个8MB的临时缓存区，然后把那些常用函数都复制到这块区域。此后，通过mmap()映射anonymous page以及madvise来创建huge page，程序代码段原来的8MB的区域就变成了一个huge page区域，再把临时缓存区的内容copy回来，并且用mprotect()来把这块区域继续设置为可执行代码区域。

这一系列操作之后，kernel什么都不用改，就能获得5~10%的性能提升。不过THP区域的符号地址以及uprobe target就乱掉了，因为kernel没有意识到这块区域还是程序代码段的一部分。假如文件系统代码里面支持了THPs，那就不用搞这么多复杂的小动作，直接用一个madvise()命令来达成即可。

Liu希望能完成filesystem里面相关的代码，不过他所实现的代码里面还是有很多限制和简化。例如，不支持对THP内存区域的写入操作。大家对这里的操作有不小分歧。一位参会者问他为何部支持写操作，是因为性能问题，还是因为代码太复杂。Johannes Weiner解释说如果要加write支持的话，就意味着要修改filesystem里面所有需要用到page结构的代码。特别是所有的文件系统都要被修改了。所以为了避免用一个巨大的patch来一次修改完所有文件，他们采取了一个简洁的修改作为第一步，当然这不会是最终版本。

Kirill Shutemov和Matthew Wilcox有点担心，不支持写入的话，这个代码很难被合入Linux kernel。Chris Mason认为Facebook所描述的这种应用场景，确实不需要写操作。Wilcox坚持认为这个方案太不通用了。Rik van Riel认为大家都应该牢记一点，要想把这么大的一个改动一次性合入kernel，简直是不可能完成的任务。这个patch太大了，还是需要确定第一阶段应该完成什么。Shutemov和Wilcox很坚定的认为，不支持write操作的话，就没有理由合入kernel。

Wilcox倒是提到，他在做的page cache的一些改动（minimizing the tail pages, https://lwn.net/Articles/787388/ ) 会能简化文件系统里相关的支持。具体来说，能够把所有那些针对compound page来返回tail page的函数都拿掉。这样文件系统代码就只需要处理head page即可。他建议等他的代码完成之后，在此基础之上来加文件系统的THP支持。Shutemov比较赞同这个想法。当然这可能不是Liu最希望从这个讨论中看到的结果，没关系，Facebook还是可以继续在内部使用它现有的方案作为过渡。

全文完

极度欢迎将文章分享到朋友圈 
热烈欢迎随意转载，只需保留出处～

长按下面二维码关注：Linux News搬运工，希望每周的深度文章以及开源社区的各种新近言论，能够让大家满意～