Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Original file line number Diff line number Diff line change
@@ -0,0 +1,25 @@
# 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

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 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)
25 changes: 25 additions & 0 deletions chapters/compute/copy-on-write/guides/fork-faults/README.md
Original file line number Diff line number Diff line change
Expand Up @@ -21,6 +21,31 @@ The first one still corresponds to the parent.

[Quiz 2](../tasks/questions/child-faults-after-write.md)

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)

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.
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -9,7 +9,7 @@

#include "utils/utils.h"

#define NUM_PAGES 1024
#define NUM_PAGES 256

static void wait_for_input(const char *msg)
{
Expand Down
1 change: 1 addition & 0 deletions config.yaml
Original file line number Diff line number Diff line change
Expand Up @@ -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
Expand Down