标题：通过一个奇怪的技巧让你的 QEMU 快 10 倍
URL 来源：https://linus.schreibt.jetzt/posts/qemu-9p-performance.html
Markdown 内容：
这篇关于 QEMU 的工作和文章由 Determinate Systems 资助，并在 Determinate Systems 博客 上共同发布。
背景
NixOS 广泛使用基于 QEMU 的虚拟机来运行其测试套件。为了避免为每个测试生成磁盘镜像，测试驱动程序通常使用 Plan 9 文件协议 (9p) 共享（由 QEMU 实现的服务器）来引导 Nix 存储，其中包含测试所需的所有程序和配置。
我正在进行一个虚拟机测试，该测试从 9p 挂载的 Nix 存储中复制了相当大量的数据（约 278k 个文件，总计约 5.3GiB），并对复制这些数据所需的时间感到惊讶。在 NVMe 设备上，我预计这需要几秒钟或几分钟，但实际上测试花费了超过 2 小时，其中大部分时间用于从 9p 复制文件。由于这对于增量工作来说是不可接受的，我决定深入研究一下，并将测试时间减少到仅 7 分钟。在这篇文章中，我将描述整个过程。
分析 QEMU
作为前言：我在调试性能问题方面没有太多经验！我使用的大多数工具对我来说都是新鲜的。我首先想要找出大量时间花费在哪里。我猜测是在 QEMU 而不是在客户机中，尽管这个猜测的正确性纯属运气。这个 Stack Overflow 问题 描述了一个与我的问题大致相似但不完全相同的问题。这引导我尝试使用 穷人的分析器，这是一个由 gdb、一些 shell 和 awk 组成的小黑客。
惊讶和失败的故事：穷人的分析器
我立即在这种方法上遇到了一个小障碍。gdb 说：
警告：目标和调试器在不同的 PID 命名空间中；线程列表和其他数据可能不可靠。连接到容器内的 gdbserver。
Nix 使用 Linux 命名空间为构建提供一些与运行构建的系统隔离，以减少特定机器环境对构建结果的影响（“纯度”）。这包括 PID 命名空间，它们阻止命名空间内的进程接触命名空间外的任何进程。gdb 对于在与其目标进程不同的 PID 命名空间中感到不满！我首先尝试使用 nsenter 将我的 gdb 放入沙箱中。我在这里遇到的第一个惊讶是，进入 PID 命名空间并不会导致 procps 的实用程序（如 ps、pgrep 和 top）仅报告新命名空间内的进程：
[root@oak:~]# pgrep -a qemu
1678991 /nix/store/6shk4z9ip57p6vffm5n9imnkwiks9fsa-qemu-host-cpu-only-for-vm-tests-7.0.0/bin/qemu-kvm [...]
[root@oak:~]# nsenter --target 1678991 --pid
标签：__,10,00,thread,qemu,gpt,fid,debug,QEMU
From： https://www.cnblogs.com/math/p/18612339/translate-make-qemu-10x-faster-by-fix-a-little-bug