字节跳动在过去几年中一直在积极优化 Linux 内核，最近的贡献是提升使用 Kexec 重启内核的速度。原因在于他们的产品越来越流行，比如抖音及其海外版，以及其他应用都需要依赖大量 Linux 服务器，所以字节跳动工程师会尽其所能优化 Linux 内核，将服务器的启动/重启时间缩短几毫秒，以减少服务器停机时间。这就是他们参与大多数 Linux 优化的目的，包括这个最新的补丁系列——以实现更快的 Kexec 重启。
和许多其他大型组织一样，出于安全、维护和优化的原因，字节跳动依靠 Kexec 重启来迁移到新的内核。通过使用 Kexec，他们避免了服务器 POST'ing 和其他任务发生严重停机时间。不过即便使用了 Kexec 来切换到一个新的内核，以避免硬件初始化，但引导加载程序仍可能会导致停机时间过长。
字节跳动最新贡献的"faster kexec reboot"系列补丁如名字所示，可加快 Kexec 的重启速度。他们的优化目标是减少大约 500 毫秒的时间，将机器使用 Kexec 启动内核功能的时间缩短到只有 15 毫秒。
目前这个补丁系列涉及到了大约 100 行 Linux 内核代码，字节跳动希望能在上游将 Kexec 重启时间缩短半秒左右。
字节跳动提出的优化措施包括：在 x86/x86_64 上支持启用未压缩的内核，以加快启动过程，而不是压缩内核镜像，避免在内核未压缩时进行内存拷贝，以及将已崩溃的内核所保留的内存重新用于正常的 kexec 操作。经测试，仅在 x86 上启用未压缩内核就可以将启动时间缩短 150 毫秒以上，但这意味着内核镜像大小从 8.5M 增加到 53M。
字节跳动技术人员表示：“「faster kexec reboot」系列补丁有针对性的场景，即服务器的内核快速热升级，在尽量不影响业务的前提下在线升级 Linux 内核版本。另外，此次向社区提交的补丁代码，只是内核优化整体项目中的一小部分，我们计划在一些技术会议上分享我们的整体优化方案，并考虑开源更多的代码。”
How are you handling driver shutdown and restart? I would expect those
to be a larger piece of the puzzle than memory.
My desktop can do something like 128GiB/s. Which would suggest that
copying 128MiB of kernel+initrd would take perhaps 10ms. The SHA256
implementation may not be tuned so that could be part of the performance
issue. The SHA256 hash has a reputation for having fast
implementations. I chose SHA256 originally simply because it has more
bits so it makes the odds of detecting an error higher.
If all you care about is booting a kernel as fast as possible it make
make sense to have a large reserved region of memory like we have for
the kexec on panic kernel. If that really makes sense I recommend
adding a second kernel command line option and a reserving second region
of reserved memory. That makes telling if the are any conflicts simple.
I am having a hard time seeing how anyone else would want these
kexec: reuse crash kernel reserved memory for normal kexec
kexec: add CONFING_KEXEC_PURGATORY_SKIP_SIG
x86: Support the uncompressed kernel to speed up booting
x86: boot: avoid memory copy if kernel is uncompressed