tmp: enable huge pages by default

To do some performance testing comparing huge pages with small pages.

Signed-off-by: Patrick Roy <[email protected]>

Author: roypat

.buildkite/common.py

@@ -19,7 +19,6 @@
 ]
 
 DEFAULT_PLATFORMS = [
-    ("al2", "linux_4.14"),
     ("al2", "linux_5.10"),
     ("al2023", "linux_6.1"),
 ]

.buildkite/pipeline_perf.py

@@ -34,11 +34,6 @@
         "test_path": "integration_tests/performance/test_network_ab.py::test_network_tcp_throughput",
         "devtool_opts": "-c 1-10 -m 0",
     },
-    "snapshot-latency": {
-        "label": "📸 Snapshot Latency",
-        "test_path": "integration_tests/performance/test_snapshot_ab.py",
-        "devtool_opts": "-c 1-12 -m 0",
-    },
     "vsock-throughput": {
         "label": "🧦 Vsock Throughput",
         "test_path": "integration_tests/performance/test_vsock_ab.py",

src/vmm/src/vmm_config/machine_config.rs

@@ -53,11 +53,11 @@ impl From<kernel_version::Error> for VmConfigError {
 #[derive(Clone, Copy, Debug, Default, PartialEq, Eq, Serialize, Deserialize)]
 pub enum HugePageConfig {
     /// Do not use hugepages, e.g. back guest memory by 4K
-    #[default]
     #[serde(alias = "4K")]
     None,
     /// Back guest memory by 2MB hugetlbfs pages
     #[serde(rename = "2M")]
+    #[default]
     Hugetlbfs2M,
     /// Back guest memory by 1GB hugetlbfs
     #[serde(rename = "1G")]

tests/integration_tests/performance/test_memory_overhead.py

@@ -65,6 +65,7 @@ def test_memory_overhead(
         ps = psutil.Process(microvm.firecracker_pid)
 
         for pmmap in ps.memory_maps(grouped=False):
+            print(pmmap)
             # We publish 'size' and 'rss' (resident). size would be the worst case,
             # whereas rss is the current paged-in memory.
 

tools/devtool

@@ -691,18 +691,19 @@ cmd_test() {
 
         apply_performance_tweaks
       fi
+    fi
 
-      # It seems that even if the tests using huge pages run sequentially on ag=1 agents, right-sizing the huge pages
-      # pool to the total number of huge pages used across all tests results in spurious failures with pool depletion
-      # anyway (something else on the host seems to be stealing our huge pages, and we cannot "ear mark" them for
-      # Firecracker processes). Thus, just allocate 4GB of them and call it a day.
-      say "Setting up huge pages pool"
-      num_hugetlbfs_pages=2048
+    # It seems that even if the tests using huge pages run sequentially on ag=1 agents, right-sizing the huge pages
+    # pool to the total number of huge pages used across all tests results in spurious failures with pool depletion
+    # anyway (something else on the host seems to be stealing our huge pages, and we cannot "ear mark" them for
+    # Firecracker processes). Thus, just allocate 4GB of them and call it a day.
+    say "Setting up huge pages pool"
+    num_hugetlbfs_pages=51200 # 100GiB huge pages pool
+
+    # Allocate enough 2M hugetlbfs pages to boot a single 128MB microvm
+    huge_pages_old=$(cat /sys/kernel/mm/hugepages/hugepages-2048kB/nr_hugepages)
+    huge_pages_new=$(echo $num_hugetlbfs_pages |sudo tee /sys/kernel/mm/hugepages/hugepages-2048kB/nr_hugepages)
 
-      # Allocate enough 2M hugetlbfs pages to boot a single 128MB microvm
-      huge_pages_old=$(cat /sys/kernel/mm/hugepages/hugepages-2048kB/nr_hugepages)
-      huge_pages_new=$(echo $num_hugetlbfs_pages |sudo tee /sys/kernel/mm/hugepages/hugepages-2048kB/nr_hugepages)
-    fi
 
     if [[ "$huge_pages_new" -ne "$num_hugetlbfs_pages" ]]; then
       die "Failed to allocate $num_hugetlbfs_pages hugetlbfs pages, only got $huge_pages_new"