From af8722992ae207f3983da4a14dbceb254b511b7c Mon Sep 17 00:00:00 2001 From: robertmercea Date: Wed, 21 Jan 2026 01:04:54 +0200 Subject: [PATCH 1/2] compute/drills: Add a new quiz about Transparent Huge Pages - Change NUM_PAGES to 256 in the original code to avoid Transparent Huge Pages (THP) being triggered, allowing students to properly view the expected page fault numbers, as shown in the course material - Create a new quiz about THP, explaining the low number of page faults caused by the program, despite increasing the page count - Add the new quiz in config.yaml Signed-off-by: robertmercea --- .../drills/questions/huge-page-allocation.md | 26 +++++++++++++++++++ .../guides/fork-faults/README.md | 5 ++++ .../guides/fork-faults/support/fork_faults.c | 2 +- config.yaml | 1 + 4 files changed, 33 insertions(+), 1 deletion(-) create mode 100644 chapters/compute/copy-on-write/drills/questions/huge-page-allocation.md diff --git a/chapters/compute/copy-on-write/drills/questions/huge-page-allocation.md b/chapters/compute/copy-on-write/drills/questions/huge-page-allocation.md new file mode 100644 index 0000000000..a4e7c8eda1 --- /dev/null +++ b/chapters/compute/copy-on-write/drills/questions/huge-page-allocation.md @@ -0,0 +1,26 @@ +# Huge Page Allocation + +## Question Text + +How many page faults are registered between step 1 and step 2 after changing `NUM_PAGES` to 1024? + +## Question Answers + +- 1024 + +- 1023 + +- 0 + ++ 2 + +- 512 + +## Feedback + +Only **two** page faults have been triggered thanks to an optimization mechanism called **Transparent Huge Pages (THP)**. +The code maps 1024 pages of 4 kb each in a _contiguous memory region_. +The kernel attempts to merge them into 2 huge pages of 2 mb each. +This way, we only need 2 TLB entries (instead of 1024) to address our memory, which reduces TLB misses and improves performance. +Those 2 entries are then mapped to physical memory, causing the page faults. +You may read more about THP in these [docs from RedHat](https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/6/html/performance_tuning_guide/s-memory-transhuge) or from the [Linux kernel](https://www.kernel.org/doc/Documentation/vm/transhuge.txt) diff --git a/chapters/compute/copy-on-write/guides/fork-faults/README.md b/chapters/compute/copy-on-write/guides/fork-faults/README.md index aa06880aaa..1d812d7c2e 100644 --- a/chapters/compute/copy-on-write/guides/fork-faults/README.md +++ b/chapters/compute/copy-on-write/guides/fork-faults/README.md @@ -21,6 +21,11 @@ The first one still corresponds to the parent. [Quiz 2](../tasks/questions/child-faults-after-write.md) +As a bonus, try changing `NUM_PAGES` to a bigger number, such as 1024. +Compile the program, run it again and see the effects. + +[Quiz 3](../tasks/questions/huge-page-allocation.md) + Now it should be clear how demand paging differs from copy-on-write. Shared memory is a similar concept. It's a way of marking certain allocated pages so that copy-on-write is disabled. diff --git a/chapters/compute/copy-on-write/guides/fork-faults/support/fork_faults.c b/chapters/compute/copy-on-write/guides/fork-faults/support/fork_faults.c index 4db7478e57..6144ef4008 100644 --- a/chapters/compute/copy-on-write/guides/fork-faults/support/fork_faults.c +++ b/chapters/compute/copy-on-write/guides/fork-faults/support/fork_faults.c @@ -9,7 +9,7 @@ #include "utils/utils.h" -#define NUM_PAGES 1024 +#define NUM_PAGES 256 static void wait_for_input(const char *msg) { diff --git a/config.yaml b/config.yaml index ad19dd9289..2ff8ec4144 100644 --- a/config.yaml +++ b/config.yaml @@ -337,6 +337,7 @@ docusaurus: - Semaphore Equivalent: semaphore-equivalent.md - Coarse vs Granular Critical Section: coarse-vs-granular-critical-section.md - Not Race Condition: not-race-condition.md + - Huge Page Allocation: huge-page-allocation.md - Lab 6 - Multiprocess and Multithread: lab6.md - Lab 7 - Copy-on-Write: lab7.md - Lab 8 - Synchronization: lab8.md From 7b8750ef3a1d04acdb7667e05be169e2bed9b440 Mon Sep 17 00:00:00 2001 From: robertmercea Date: Sat, 24 Jan 2026 21:50:03 +0200 Subject: [PATCH 2/2] compute/guides: Add details about THP and THP setup - Added details about how Transparent Huge Pages (THP) work in Linux - Added a simple guide on how to enable THP Signed-off-by: robertmercea --- .../drills/questions/huge-page-allocation.md | 5 ++-- .../guides/fork-faults/README.md | 24 +++++++++++++++++-- 2 files changed, 24 insertions(+), 5 deletions(-) diff --git a/chapters/compute/copy-on-write/drills/questions/huge-page-allocation.md b/chapters/compute/copy-on-write/drills/questions/huge-page-allocation.md index a4e7c8eda1..008ba2536f 100644 --- a/chapters/compute/copy-on-write/drills/questions/huge-page-allocation.md +++ b/chapters/compute/copy-on-write/drills/questions/huge-page-allocation.md @@ -18,9 +18,8 @@ How many page faults are registered between step 1 and step 2 after changing `NU ## Feedback -Only **two** page faults have been triggered thanks to an optimization mechanism called **Transparent Huge Pages (THP)**. -The code maps 1024 pages of 4 kb each in a _contiguous memory region_. +The code maps 1024 pages of 4 kb each for a total of 4 mb. The kernel attempts to merge them into 2 huge pages of 2 mb each. -This way, we only need 2 TLB entries (instead of 1024) to address our memory, which reduces TLB misses and improves performance. +This way, we only need 2 TLB entries (instead of 1024) to manage them. Those 2 entries are then mapped to physical memory, causing the page faults. You may read more about THP in these [docs from RedHat](https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/6/html/performance_tuning_guide/s-memory-transhuge) or from the [Linux kernel](https://www.kernel.org/doc/Documentation/vm/transhuge.txt) diff --git a/chapters/compute/copy-on-write/guides/fork-faults/README.md b/chapters/compute/copy-on-write/guides/fork-faults/README.md index 1d812d7c2e..c44c465e6a 100644 --- a/chapters/compute/copy-on-write/guides/fork-faults/README.md +++ b/chapters/compute/copy-on-write/guides/fork-faults/README.md @@ -21,8 +21,28 @@ The first one still corresponds to the parent. [Quiz 2](../tasks/questions/child-faults-after-write.md) -As a bonus, try changing `NUM_PAGES` to a bigger number, such as 1024. -Compile the program, run it again and see the effects. +As a **bonus**, you are going to learn about a Linux memory optimization mechanism called [Transparent Huge Pages (THP)](https://docs.kernel.org/admin-guide/mm/transhuge.html) and its effects on the TLB. +If we were to `mmap`, for example, 1024 _contiguous_ pages (of 4 kb each) in memory, they would occupy 1024 entries in the page table and, in turn, in the TLB. +However, they can be managed much more efficiently using THP. +It works by taking that memory region and remapping it using **huge pages** of a fixed size each (for example: 2mb). +This way, we may address the same memory using a lot less TLB entries, boosting performance. + +To enable this mechanism on your system, run the following command: + +```console +student@os:~/.../fork-faults/support$ sudo bash -c "echo always > /sys/kernel/mm/transparent_hugepage/enabled" +``` + +No need to worry about breaking anything. +It lasts only for this session (i.e. it resets on reboot). + +Now, enable THP for pages of a specific size, such as 2 mb: + +```console +student@os:~/.../fork-faults/support$ sudo bash -c "echo always > /sys/kernel/mm/transparent_hugepage/hugepages-2048kB/enabled" +``` + +Set `NUM_PAGES` to 1024 in `fork-faults.c`, recompile the program and see the results. [Quiz 3](../tasks/questions/huge-page-allocation.md)