在运行 Debian Wheezy amd64 的本地机器 (i7 9200) 上，我可以通过以下方式显著提高某些“大数据”/HPC 类型内容的加速：
该应用程序在 EC2 上的 Debian Wheezy 上运行得也相当好（我正在使用最新喘息性心肌梗死) 使用普通的 4k 页面（在 c3.2xlarge、c3.4xlarge 和 c3.8xlarge 实例上尝试了一些可扩展性测试）。但我也很好奇，如果可能的话，在 EC2 上使用大页面是否能看到类似的好处。
我启动了一个 c3.3xlarge 实例并设置了大页面照常之后 /proc/meminfo 确实报告了
HugePages_Total: 4096
HugePages_Free: 4095
然而，在编译 libhugetlbfs 之后，它的make func自检会触发一些内核错误。系统很快就似乎锁定了，但在此之前，我有时间检查 dmesg 并看到一堆包含各种符号的调用堆栈xen_。hugetlb_fault一旦它变得无响应，系统就需要从 AWS 控制台强制停止才能停止。
我确实尝试再次启动并运行我的应用程序HUGETLB_MORECORE=yes（以防make func测试在某些我实际上不需要的模糊东西上中断），但同样的事情再次发生。
任何EC2 上使用 libhugetlbfs 的成功案例（最好使用 Debian），或者使其正常工作的秘诀？
研究：关于 EC2（或 Xen）上的大页面，谷歌上的信息很少。我确实找到了这，似乎报告了相同的问题：/proc/meminfo 报告有大页面可用，但尝试使用它们会导致内核崩溃。本文早于新的 c3 实例，但建议 cc2.8xlarge 可能值得一试，因为它使用 HVM 而不是 PVM。
更新：找不到适用于 HVM 的最新 Debian AMI，但在 cc2.8xlarge 和 libhugetlbfs 上尝试了 Ubuntu AMI（13.04“raring”），HUGETLB_MORECORE=yes似乎运行良好。唯一的问题是，它实际上会减慢我的应用程序速度！