当您知道您的软件（不是驱动程序，不是操作系统的一部分，只是一个应用程序）将主要在虚拟化环境中运行时，是否有策略来优化您的代码和/或编译器设置？或者任何关于你应该做什么和不应该做什么的指南？
这不是关于 0.0x% 的性能提升，而是也许，只是也许有一些简单的事情会显着提高性能，或者一些看似简单但在虚拟化环境中众所周知的灾难性的事情。例如，在内核构建中启用 CONFIG_PARAVIRT 很容易完成，并且可以大大提高性能。现在我正在为应用程序寻找类似的东西，如果有的话。
在我的情况下，它将是 C++ 代码，可能是 VMWare，但我想尽可能地保持这个问题与语言/产品无关。我想知道是否有这样的策略，或者这是否会完全浪费时间——毕竟虚拟化的概念是你不必太在意它。
我发现这完全是关于 I/O 的。
虚拟机在 IO 上的表现通常非常糟糕。这使得各种事情比在真正的锡上要糟糕得多。
交换尤其是一个糟糕的杀手——它完全破坏了虚拟机的性能，即使是一点点，因为 IO 太慢了。
大多数实现在虚拟机之间都有大量的 IO 争用，我还没有看到一个可以避免这种情况或明智地处理它的方法。
因此，如果可以的话，请为临时文件使用 ramdisc，但不要导致它交换，因为那样会更糟。
我能给你的唯一建议是小心使用 mlock() / mlockall() .. 同时寻找有问题的气球驱动程序。
例如，如果 Xen 来宾以 1GB 启动，然后膨胀到 512 MB，特权域没有查看半虚拟化内核实际承诺给进程的内存量（即 Committed_AS）是非常典型的。实际上，对于 Xen，除非将这个值放在 Xenbus 上，否则特权主机不知道这样的气球会做什么。我相信这也与 KVM 不谋而合，具体取决于内核的配置方式.. 但您的问题假定我们对这些事情一无所知:)
所以，保护那些根本无法被分页的东西（小心，但谨慎），总是考虑到“天塌下来”的情况。
同样，使用 posix_fadvise() / posix_madvise() 告诉 PV 内核您需要或不需要缓冲多少总是一个好主意。
除此之外，您几乎无能为力......因为您只与半虚拟化内核交谈，该内核旨在使进程首先忽略虚拟化。
虽然我计划在未来更多地探索它，但我（还）不怎么使用 KVM。然而，我最近写的 90% 的东西都是专门为在半虚拟化 Xen 客户机上运行而设计的。很抱歉有点以 Xen / C 为中心，但这就是我的经验所在，pv_ops 也在主线中（很快还有 xen-0 ops）:)
好问题，顺便说一句:)
编辑：
当我说“谨慎但谨慎”时，我的意思是比保守高出一步。如果您的程序分配了大多数功能需要的一些作业结构，请将其锁定。如果您分配缓冲区来读取大文件，请不要锁定它们.. 并确保调用 posix_fadvise() 让内核知道您只打算访问它一次（如果是这种情况）。此外，请务必告知内核您使用内存映射文件，特别是如果它们用于组织并发性。
简而言之，帮助您的主机内核管理内存，不要让关键分配的块陷入脏页，不要通过锁定它分配的所有内容来假设您的程序比其他任何事情都重要:)
很抱歉模棱两可。我能想到的最好的短语是“小心，但谨慎”。
我唯一的建议是尽可能降低内存和 IO 使用率。
与物理硬件相比，VM 中的 IO 非常慢。如果你能避免这样做，那就避免它。
当系统被虚拟化时，真实硬件上慢的东西甚至更慢。这取决于所使用的虚拟化技术会变慢多少。
尤其要避免任何需要与虚拟环境之外的世界进行 I/O 的事情。根据设置的不同，这包括在屏幕上绘图、交换以及磁盘和网络 I/O。这大致按重要性递减顺序排列。
如果可能的话，假装你正在为一台使用了十年的电脑写作。如果您的应用程序可以在 1999 年的台式 PC 或笔记本电脑上运行，那么它应该可以。