我们这群90后,正在字节跳动“死磕”Linux内核 | 卓越技术团队访谈录

2012 - 2022，是字节跳动产品线快速延伸的十年，也是基础设施规模快速增长的十年。在这背后，有这样一支团队默默为字节上层业务的稳定保驾护航，他们就是字节系统部 STE 团队。

早在 2015 年，STE 团队就初具雏形，当时主要是问题驱动，为字节内部基础设施及软件系统提供技术支持。随着 2017 年抖音等热门产品用户量级大爆发、成为现象级 APP，字节内部的服务器规模愈发庞大，对系统的维护工作也成为重中之重。

2018 年，团队被正式命名为 STE（全称：System Technologies & Engineering，系统技术与工程）。如今，STE 团队已从最初的 20 人扩大至数百人规模，在英国、美国等多地设有研发中心。技术维度也从操作系统内核扩展到服务器固件、编译器技术、系统虚拟化、主机网络、系统智能运维等基础技术，并将基础软件工程能力赋能业务。

在本期访谈中，InfoQ 有幸采访到了 STE 内核方向的多位核心成员，了解他们在 Linux 内核优化上的技术实践与经验，以及这些工作为业务带来的价值，同时一窥这支专注于底层基础设施建设、在“看不见的地方”用技术构筑城墙的团队的精神和文化。

据了解，STE 内核团队是字节系统部面向公司内部所有业务提供 Linux 内核服务的团队，主要负责内核管理、进程调度、虚拟化和网络等几个方面的工作。据 STE 内核团队负责人段熊春介绍，在 2015 年 STE 团队初具雏形的时候，就有研发人员负责内核相关的工作。2018 年，STE 团队正式成立，内核方向也作为其下属团队之一，逐步扩建成有专职研发人员负责解决 Linux 内核存在的问题，并增加和维护新特性。

我们注意到，这是一支非常年轻的团队，内核维护者以 90 后居多，这其实并不常见。毕竟 “Linux 之父”Linus Torvalds 曾感慨，“目前的维护者多是 50、60 后，社区面临代际更新问题。”Linus Torvalds 甚至担心，在他们这批 Linux 内核维护者老去之后，很难再找到新的继任者，因为很多年轻开发者认为“Linux 内核项目并不那么有趣”。

STE 团队的负责人张宇深耕于系统技术领域多年，对此他也表示，“现在专注在底层基础软件、操作系统内核上的人才越来越匮乏，甚至出现了两种极端：一种是开发者的计算机基础非常扎实，底子好，但对内核研发并不感兴趣；一种是对内核非常感兴趣，但底子薄，需要补功课。同时具备这两方面优势的人才非常少。对于我们内核团队而言，年轻是我们的优势，正是这种对内核技术的痴迷和热爱，才让我们走到了一起。”

向团队中注入新鲜的血液并不难，难的是如何让这些年轻人在 Linux 内核方向愈战愈勇、愈走愈远。对此，张宇提到了两个字：激发。给年轻人平台，激发其兴趣；给年轻人机会，激发其斗志。“我们也有很多资深的开发者，但他们更倾向于把好的机会留给年轻人。这种‘传帮带’的传统，能够让年轻开发者有机会站到台前，越做越有信心。否则，如果年轻人持续得不到鼓励、不被激发，在这条艰辛的道路上就很难做出成绩、走得长远。”张宇提到。

正是在这种文化氛围的熏陶下，STE 内核团队依托于 Linux 内核，在虚拟化、云原生、eBPF 等技术方向都有非常硬核的输出。比如，2020 年 9 月，团队向 Linux 内核社区贡献了 HVO 方案，该方案能够解决 Linux 内核内存管理冗余这一难题。

从 Linus Torvalds 在 1991 年发布第一版开始，Linux 内核迄今已发展了 30 余年。据称，第一版的 Linux 内核只有 10250 行代码，占用 65 KB，而如今，Linux 内核代码行数早已超过 2700 万。

Linux 内核每年新增 / 删除的代码多达百万行，也加入了越来越多优秀的特性。这样一个复杂且臃肿的工程，在不同的业务场景下，势必会面临各式各样的挑战。

支撑字节全量服务器运转的正是 Linux 操作系统。STE 内核团队发现，一些云计算的场景会带来额外的内存管理开销，随着服务器规模越来越大，这种损耗也会成倍放大。

“Linux 内核以页（一般 4 KB）为单位管理物理内存。每个 4 KB 页对应一个 struct page 结构体。使用一个 struct page 管理一个页，这本身没什么问题。但是当使用的页的大小是 2 MB 甚至 1 GB 时，Linux 依然以 4 KB 为单位分配 struct page，这显然是个内存浪费的行为。我的目的就是尽可能减少这部分冗余的内存管理开销。”说这话的是 STE 工程师宋牧春。2019 年 7 月，宋牧春加入字节 STE 内核团队，三年时间，宋牧春随团队一同成长，也完成了从 Linux 内核开发者到 Linux 内核维护者的转变，并成为 Linux 内核社区 HugeTLB 和 Memory Cgroup 两个核心子模块的 maintainer。

实际上，Linux 内核内存管理冗余并不是一个新问题，它在业内已存在十年之久。过去不少公司都做过研究，但始终没有找到解法。即便如此，STE 内核团队依然想做一些尝试。在不断地讨论、验证各种方案的可行性后，团队发现这个问题是有可能被解决的。

“某些场景会使用到大页，每个大页需要 8 个页的 struct page 去管理，即 8X4K 的内存，我们希望最终只占用一个页的物理内存（4KB）。对此，我们想的方案是复用，把后面 7 个虚拟地址映射到唯一的物理页，如果方案能成功落地，则意味着 1T 的服务器，最大能节省接近 16GB 的内存。即使优化 1%，整体给公司带来的收益也会非常大。”宋牧春说道。

这套方案被称作 HVO (HugeTLB Vmemmap Optimization)。方案有了，下一步就是做代码调研。

Linux 内核管理是非常复杂且核心的一个模块，它和各个模块交织在一起，它的稳定性也必然会影响整个 Linux 内核的稳定性。因此，STE 内核团队需要尽可能地减少该方案代码涉及的范围，并确保不会影响系统里的其他功能。为此，从 2020 年 4 月到 2021 年 6 月，团队开始了长达一年时间的代码调研、开发、测试和重构。

用一年的时间，解决一个技术难题，值得吗？段熊春给出了肯定的回答。

“我们会衡量这件事情的价值，显然我们也面临着很多压力，但真正难的事情是需要投入更多时间去看的，我们也需要这样做。基于对技术的狂热，我们周末也经常聚在一起讨论和思考，再把这些想法带到实际场景中，更好的打磨和优化。这是一个长期的过程，而这些突破也能为公司和业界带来巨大的收入，这就是有价值的。”

同时，HVO 也得到了业界的广泛认可：华为、Google、AWS、甲骨文都准备将这个方案投入使用，还有公司向团队发来感谢信。“但这不是终点，我们会持续优化 HVO 方案。”段熊春说道。

设备虚拟化技术作为云计算领域最重要的基础技术之一，多年来一直在稳步向前演进。其中，virtio 和 VFIO 在过去一直是最主流的设备虚拟化技术，并分别于 2008 年、2012 年被合入 Linux 内核主线。为了将 virtio 和 VFIO 的优势结合，2020 年，vDPA（Virtio Data Path Acceleration）技术框架被合入 Linux 内核主线。

与此同时，字节内部的云原生化进程也在进行着。

据了解，字节最早于 2016 年开始在内部推进云原生化进程，对业务进行大规模容器化改造。到 2021 年年末，字节已经有超过 95% 的应用实现了云原生化。在这个过程中，STE 内核团队发现，容器在一些 I/O 相关的解决方案中，与传统的虚拟化方案相比比较受限。“我们当时希望能够在 Linux 内核中提供一套框架，开发者可以基于这个框架去模拟各种各样的设备，并且能够直接供容器接入使用。这样，就进一步弥补了基于容器的云原生方案在 I/O 方面的短板，甚至还能够和相对成熟的虚拟化方案实现一定程度上的技术复用。”STE 工程师谢永吉对 InfoQ 说道。

于是，VDUSE 框架应运而生。通过 VDUSE，开发者可以在一个用户进程中实现一个软件定义的 vDPA 设备，并可以通过 vDPA 框架接入 virtio 或者 vhost 子系统，供容器或者虚机使用。

根据介绍，具体的实现原理上，VDUSE 设备是由 /dev/vduse/control 的 ioctl(VDUSE_CREATE_DEV) 创建的，通过这个 ioctl，用户空间可以为这个模拟设备指定一些基本配置，如设备名称（唯一标识 VDUSE 设备）、virtio 特性、virtio 配置空间、virtqueues 数量等等。然后，一个字符设备接口（/dev/vduse/$NAME）会被导出到用户空间用于设备模拟。用户空间可以在 /dev/vduse/$NAME 上使用 VDUSE_VQ_SETUP ioctl 来初始化每个 virtqueue 的配置，如 virtqueue 的最大长度等。

在初始化之后，VDUSE 设备可以通过 VDPA_CMD_DEV_NEW 这条 netlink 消息绑定到 vDPA 总线。之后，用户空间可以在 /dev/vduse/$NAME 上通过 read()/write() 来接收并回复来自 VDUSE 内核模块的一些控制请求，同时还可以通过 mmap() 映射一段共享内存，与内核相应的 virtio 驱动进行数据通信。

2020 年 10 月，STE 内核团队向 Linux 内核社区正式开源 VDUSE。经过一年时间，VDUSE 在 Linux 5.15 版本被正式合入。

“在计算存储分离的架构下，我们可以在计算节点通过 VDUSE 框架模拟各类存储设备供容器或虚机使用，这类存储设备的后端往往是远端的存储节点。现在，这套解决方案在字节的云原生场景已经开始大规模部署。后续，我们也将继续探索在云原生高性能网络场景上的应用可行性。”谢永吉说道。

Linux 内核始终在向前演进，在 STE 工程师邓良看来，“随着云原生应用场景不断扩大、硬件朝着高密度应用异构的机型上发展，对 Linux 内核提出了新的要求。内核是连接底层硬件和上层云原生应用的一个桥梁，我们也在思考，当前这种单一的宏内核是否合适，并且我们也在做一些探索。”

如果说攻克技术难关靠的是技术硬实力，那么向社区推广并使其合入我们的代码，则要依靠足够多的耐心去沟通和布道。

在与社区沟通上，STE 内核团队也积累了自己的经验。

2020 年 9 月，当 HVO 第一个版本发到社区后，团队收到很多质疑的声音。“社区起初对我们的方案产生怀疑，我们需要先向社区证明这个方案没有问题。同时，社区也会提出一些针对性的问题，甚至有很多都是我们之前没有考虑过的场景。根据这些问题，我们再对方案进行迭代和维护。像 HVO，我们迭代了 20 多个版本，需要不断地向社区证明这个方案在不同场景的有效性，这个过程持续了很长的时间。”回忆 HVO 的社区之路，宋牧春觉得特别漫长。在他看来，社区需要考虑维护成本是否大于收益，这无可厚非，作为开发者和社区贡献者，要做的就是解释清楚技术方案能够产生的价值，让社区看到它带来的收益，并证明这个方案的可行性和稳定性。

在企业内部，一套技术方案从开发到应用，这个链路并不复杂。但面向社区，开发人员需要考虑的问题就会更多。“很多时候，我们要突破自有场景，去看社区里的其他场景和痛点，而这些很可能是我们从来没有遇到过的。”显然，拥抱社区的沟通成本会很高，但在段熊春看来，为社区贡献代码能够实现双赢，这都是值得的。

“现在我们的工作环境基本是模拟社区环境，工作模式也跟社区保持一致。这种标准化的作业模式能有效降低代码的维护成本，同时社区思维的开阔性，也为我们思考问题提供了更多的思路，进而为技术创造价值提供了更多的可能性。”

对于 STE 内核团队的愿景和目标，张宇用了三个“贴近”来描述：贴近业务，去了解业务的痛点；贴近社区，去了解社区的方向；贴近新硬件技术，在软硬协同设计上发挥内核更大价值。内核本身无法直接创造价值，更多是通过服务业务来创造价值。所以团队在做研发时，一定要想清楚对业务的收益是什么，它能否真正的解决业务痛点，进而创造业务价值。

STE 内核团队多年来一直深入社区。基于开源 Linux 操作系统，团队做了一些优化以满足企业内部的需求，反之，团队也会把这些好的特性回馈给社区，像前文提到的 HVO 和 VDUSE 都已被合入 Linux 内核主线。在张宇看来，STE 内核团队并不是要做一个标新立异的操作系统，更多的是源自技术初心，希望能够把自身的力量贡献给社区，交给 Linux，再不断引进。

张宇表示，STE 团队非常重视“务实”，这也是字节的核心价值观之一。“我们在做的事情都是围绕基础设施展开的，提高它的稳定性、优化性能等等，与公司内其他能直接创造收益的明星产品相比，我们是一个做减法的部门，通过技术手段降低基础设施成本，在业务链路里属于非常靠后的位置，就像足球场上的后卫一样，要能守住系统稳定性 / 可靠性的基本盘不出问题，又要能够往前场助攻进球。回到团队的愿景来看，我的想法比较简单务实，希望团队先满足业务的需求，再高于业务需求、先于业务需求，做一些引领业界的技术。就像一开始，我们是跟着社区，跟着业界领先者的路径去走，但随着我们技术能力不断提升以满足业务场景多样性的需求，再往前走，必将进入‘无人区’。”

进入“无人区”后，没有方向的指引，也没有参照物，这才是最考验团队能力和韧性的时候。“我希望团队有开拓精神，辨识出合理的方向并坚定的走下去，也许在过程中会有微调，但最后顶多画出来的路线是波浪线，而不是一条完全没有目标的曲线。”张宇说道。

直到今天，团队对 HVO 的优化还在继续。2022 年 3 月，团队优化了 HVO 在 2 MB HugeTLB 的表现，与此前相比，它进一步将 2 MB HugeTLB 的 struct page 开销减少了 12.5%；2022 年 4 月，HVO 支持 ARM 64 架构；2022 年 5 月，HVO 支持运行时开关，不再束缚于 cmdline 的方式使能。

依托 Linux 内核，团队在虚拟化、云原生、eBPF 等技术方向上也在继续探索着。

“现在我们关注的比较多的场景，一个是云原生，这也是大家都在关注的方向，但当前并没有一个特别好的解决方案，甚至在云游戏的一些基础设施场景下，业界还没有形成一个标准；另一个就是软硬协同，用软件的方式定义硬件，用硬件的方式来定义软件。目前我们也围绕这些方向在做一些研究。”张宇认为，“如果团队一直在做一些重复的事情，是没有激情与战斗力的，对团队的期待还是要在满足业务需求之上，去做一些引领业界的事情。”

在张宇看来，做操作系统这类基础软件不是一时热情，是需要长期投入的。大浪淘沙沙去尽，沙尽之时见真金。“目前国内外大厂也都在围绕自己的业务场景做软硬一体的事情，涉及基础系统软件、芯片板卡服务器之类的硬件研发。在做的同时也要上升到社会责任感的层面上来看，能贡献多少力量。这些都是需要持续思考的。”

张宇，字节跳动 STE 团队负责人

段熊春，字节跳动 STE 内核团队负责人

宋牧春，字节跳动 STE 工程师、Linux 内核社区 HugeTLB 和 Memory Cgroup 两个核心子模块的 maintainer

谢永吉，字节跳动 STE 工程师

邓良，字节跳动 STE 工程师