汽车行业正在发生令人着迷的变化。汽车制造商正在摒弃离散的电子控制单元（ECU），转而将计算资源整合到更大、高性能的计算机中。向更加动态的系统过渡，实现软件定义的汽车（SDV），将两个过去分离的领域融合在一起：汽车和以数据中心为中心的IT行业。

红帽是这一转变中的重要参与者。2022年，红帽宣布开发红帽车载操作系统（In-Vehicle OS），这是一个通用的车载操作系统，注定将成为SDV的未来。同年晚些时候，我们发布了一篇博客，介绍了在汽车中运行容器是推动向SDV演进的过程。

话虽如此，这两个领域之间仍存在很多差异，其中包括对系统速度和响应性的期望。

在数据中心的世界里，服务器启动可能需要几分钟时间，重新启动的频率有时可能只有一年一次。在这种环境下，容器中应用启动需要几秒钟的额外时间是无关紧要的。

然而，在汽车中，系统必须在几秒钟内启动，并且几乎每次车辆经历电源循环时都会重新启动。此外，系统启动并可用所需的时间也与用户体验有关。当我们上车时，希望能立即开车。多等一秒都是不愉快的。延迟让我们感觉系统在阻碍我们的行动。

在构建红帽车载操作系统时，我们意识到了系统速度和响应性期望方面的差异。这给了我们一个机会，去研究通过Podman启动容器应用所带来的开销，这是我们之前没有过多关注的问题。

Dan Walsh在他的博客文章中发布了这次调查的结果：如何实现Podman启动速度增加6倍。Dan的调查探索了不同的优化领域，但他并未对如何分析这些改进提出建议。一种追踪和分析性能的方法是使用eBPF技术。

eBPF是一种Linux内核技术，可以对内核进行灵活且安全的仪表化，而无需对内核代码本身进行任何更改。它可用于监控、保护和优化各种系统，包括车辆中的系统。eBPF具有许多优点，但也有一些限制。eBPF程序必须使用受限指令集编写，这在某些用例中可能具有一定限制。开发人员可能需要找到解决方法或优化措施来实现所需的功能。

此外，内核验证器试图防止潜在的安全风险，对程序的复杂性和循环结构施加了限制。这可能限制了可以使用eBPF实现的程序范围。对特定内核结构的访问是有限的。尽管跟踪点提供了与之交互的稳定API，但根据用例的不同，开发人员可能需要将kprobe附加到内核函数上，这不能保证其在内核版本之间的签名稳定性。

在Fedora或RHEL上运行分析容器启动时的eBPF程序相对简单，但在AutoSD上执行相同的步骤需要一些额外的工作。