Skip to content

Commit 5b84862

Browse files
committed
doc: include interaction of dirty page tracking with hugepages
Extend the limitation section of the huge pages docs to include a note about how dirty page tracking negates the benefits of huge pages. Also add a cross-reference to the diff snapshot docs. Signed-off-by: Patrick Roy <roypat@amazon.co.uk>
1 parent 9429bc6 commit 5b84862

File tree

2 files changed

+9
-3
lines changed

2 files changed

+9
-3
lines changed

docs/hugepages.md

Lines changed: 6 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -24,9 +24,7 @@ pool, please refer to the [Linux Documentation][hugetlbfs_docs].
2424
Restoring a Firecracker snapshot of a microVM backed by huge pages will also use
2525
huge pages to back the restored guest. There is no option to flip between
2626
regular, 4K, pages and huge pages at restore time. Furthermore, snapshots of
27-
microVMs backed with huge pages can only be restored via UFFD. Lastly, note that
28-
even for guests backed by huge pages, differential snapshots will always track
29-
write accesses to guest memory at 4K granularity.
27+
microVMs backed with huge pages can only be restored via UFFD.
3028

3129
When restoring snapshots via UFFD, Firecracker will send the configured page
3230
size (in KiB) for each memory region as part of the initial handshake, as
@@ -40,6 +38,11 @@ Firecracker features:
4038

4139
- Memory Ballooning via the [Balloon Device](./ballooning.md)
4240

41+
Furthermore, enabling dirty page tracking for hugepage memory negates the
42+
performance benefits of using huge pages. This is because KVM will
43+
unconditionally establish guest page tables at 4K granularity if dirty page
44+
tracking is enabled, even if the host users huge mappings.
45+
4346
## FAQ
4447

4548
### Why does Firecracker not offer a transparent huge pages (THP) setting?

docs/snapshotting/snapshot-support.md

Lines changed: 3 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -318,6 +318,9 @@ in the snapshot by instead considering all pages that were _accessed_ during the
318318
VM's lifetime. This potentially results in bigger memory files (although they
319319
are still sparse), but avoids the runtime overhead of dirty page logging.
320320

321+
*Note*: Dirty page tracking negates most of the benefits of
322+
[huge pages](../hugepages.md#known-limitations).
323+
321324
Without dirty page tracking enabled, Firecracker uses the
322325
[`mincore(2)`][man mincore] syscall to determine which pages to include in the
323326
snapshot. As such, this mode of snapshot taking will only work _if swap is

0 commit comments

Comments
 (0)