|
1 | 1 | --- |
2 | | -title: Page Size Overview |
| 2 | +title: Overview |
3 | 3 | weight: 2 |
4 | 4 | ### FIXED, DO NOT MODIFY |
5 | 5 | layout: learningpathall |
6 | 6 | --- |
7 | 7 |
|
8 | | -## How does the CPU locate data in memory? |
| 8 | +## Page size fundamentals |
9 | 9 |
|
10 | | -When your program asks for a memory address, the CPU doesn’t directly reach into RAM or swap space for it; that would be slow, unsafe, and inefficient. |
11 | | - |
12 | | -Instead, it goes through the virtual memory system, where it asks for a specific chunk of memory called a page. Pages map virtual memory locations to physical memory locations in RAM or swap space. |
| 10 | +Before you modify the Linux kernel page size on an Arm system, you need to know what a page is, why size matters, and how size affects performance. |
13 | 11 |
|
14 | 12 | ## What’s a memory page? |
15 | 13 |
|
16 | | -Think of your computer’s memory like a big sheet of graph paper. Each page is one square on that sheet. The page table is the legend that identifies which square (virtual address) maps to which spot in physical RAM. On x86, 4K is the only page size option, but Arm-based systems allow you to use 4K, 16K, or 64K page sizes to fine tune the performance of your applications. |
| 14 | +Think of your computer’s memory like a big sheet of graph paper. Each page is one square on that sheet. |
| 15 | + |
| 16 | +The page table acts like a legend on the map, showing which virtual address square corresponds to a specific location in physical RAM. This mapping is managed by the operating system and the CPU’s Memory Management Unit (MMU). |
| 17 | + |
| 18 | +To keep track of these mappings efficiently, CPUs use a fast lookup cache called the Translation Lookaside Buffer (TLB). Every access first attempts a TLB hit; a miss forces a page table lookup. If the page isn't already in the TLB, the CPU must fetch the mapping from memory—a process that adds latency and stalls execution. |
| 19 | + |
| 20 | +On x86 systems, 4K pages are the standard, while Arm-based systems support multiple page sizes - typically 4K, 16K, or 64K. This flexibility allows developers to fine-tune performance for specific workloads. |
17 | 21 |
|
18 | 22 | This Learning Path explains how to switch between 4K and 64K pages on different Linux distributions. |
19 | 23 |
|
20 | | -## How should I select the memory page size? |
| 24 | +## How does the CPU locate data in memory? |
21 | 25 |
|
22 | | -Points to consider when thinking about page size: |
| 26 | +When your program accesses a memory address, the CPU doesn’t directly fetch data from RAM or swap space for it. That would be slow, unsafe, and inefficient. Direct physical access would bypass isolation and invalidate caches. |
| 27 | + |
| 28 | +Instead, it goes through the virtual memory system, where it asks for a specific chunk of memory called a page. Pages map virtual memory locations to physical memory locations in RAM or swap space. |
23 | 29 |
|
24 | | -- **4K pages** are the safe, default choice. They let you use memory in small slices and keep waste low. Since they are smaller, you need more of them when handling larger memory footprint applications. This creates more overhead for the operating system to manage, but it may be worth it for the flexibility. They are great for applications that need to access small bits of data frequently, like web servers or databases with lots of small transactions. |
| 30 | +## How does page size affect performance? |
25 | 31 |
|
26 | | -- **64K pages** shine when you work with large, continuous data such as video frames or large database caches because they cut down on management overhead. They will use more memory if you don’t use the whole page, but they can also speed up access times for large data sets. |
| 32 | +Changing the page size has a cascading effect on system performance: |
27 | 33 |
|
28 | | -When selecting your page size, it's important to try both options under real-world conditions, as it will depend on the data size and retrieval patterns of the data you are working with. |
| 34 | +**Memory Fragmentation**: Smaller pages reduce internal fragmentation, which is the wasted memory per allocation. Larger pages can increase waste if your workloads don’t use the full page. |
29 | 35 |
|
30 | | -In addition, the page size may need to be reviewed over time as the application, memory usage patterns, and data sizes may change. |
| 36 | +**TLB Pressure**: With smaller pages such as 4K, more entries are needed to map the same amount of memory. This increases TLB misses and page-table-walk overhead. Larger pages, such as 64K, reduce the number of entries and can lower TLB pressure. |
31 | 37 |
|
| 38 | +**I/O Efficiency**: Disk I/O and DMA operations often perform better with larger pages, because fewer page boundaries are crossed during transfers (fewer interrupts, larger DMA bursts). |
32 | 39 |
|
33 | | -### Summary of page size differences |
| 40 | +### Trade-offs to consider |
34 | 41 |
|
35 | 42 | | Aspect | 4K Pages | 64K Pages | |
36 | 43 | |-----------------|--------------------------------------|----------------------------------------| |
37 | 44 | | **Size** | Small “bricks” (4 KB each) | Big “bricks” (64 KB each) | |
38 | | -| **Flexibility** | Very flexible—good for lots of tiny bits of data | Less flexible—best when data comes in large chunks | |
| 45 | +| **Flexibility** | Best for flexibility and compatibility | Best for large, contiguous memory workloads | |
39 | 46 | | **Efficiency** | Needs more entries (more bookkeeping) | Needs fewer entries (less bookkeeping) | |
40 | | -| **Waste** | At most 4 KB unused per page | Up to 64 KB unused if not fully used | |
| 47 | +| **Waste** | At most 4 KB unused per page | Up to ~63 KB unused if not fully used | |
| 48 | +| **TLB reach** | Lower, more misses | Higher, fewer misses | |
| 49 | + |
| 50 | +This Learning Path covers switching between 4K and 64K page sizes because these are supported by most Arm Linux distributions. In some cases, you may find that 16K page size is a sweet spot for your application, but Linux kernel, hardware, and software support is limited. One example of 16K page size is [Asahi Linux](https://asahilinux.org/). |
| 51 | + |
| 52 | +## How do I select the memory page size? |
| 53 | + |
| 54 | +Points to consider when thinking about page size: |
| 55 | + |
| 56 | +- **4K pages** are the safe, default choice. They let you use memory in small slices and keep waste low. Since they are smaller, you need more of them when handling larger memory footprint applications. This creates more overhead for the operating system to manage, but it may be worth it for the flexibility. They are great for applications that need to access small bits of data frequently, like web servers or databases with lots of small transactions. |
| 57 | + |
| 58 | +- **64K pages** shine when you work with large, contiguous data such as video frames or large database caches because they cut down on management overhead. They will use more memory if you don’t use the whole page, but they can also speed up access times for large data sets. |
| 59 | + |
| 60 | +Choosing the right page size depends on how your application uses memory, as both the data size and retrieval patterns of the data you are working with are influencing factors. Benchmark different options under real-world workloads to determine which delivers better performance. |
41 | 61 |
|
42 | | -This Learning Path covers switching between 4K and 64K page sizes because these are supported by most Arm Linux distributions. In some cases, you may find that 16K page size is a sweet spot for your application, but Linux kernel, hardware, and software support is limited. One example of 16k page size is [Asahi Linux](https://asahilinux.org/). |
| 62 | +In addition, the page size might need to be reviewed over time as the application, memory usage patterns, and data sizes might change. |
43 | 63 |
|
44 | | -## Experiment to see which works best for your workload |
| 64 | +## Try out a page size for your workload |
45 | 65 |
|
46 | 66 | The best way to determine the impact of page size on application performance is to experiment with both options. |
47 | 67 |
|
48 | | -{{% notice Do not test on Production%}} |
49 | | -Modifying the Linux kernel page size can lead to system instability or failure. Perform testing in a non-production environment before applying to production systems. |
| 68 | +{{% notice Warning%}} |
| 69 | +Do not modify the Linux kernel page size in a production environment. It can lead to system instability or failure. Perform testing in a non-production environment before applying to production systems. |
50 | 70 | {{% /notice %}} |
51 | 71 |
|
52 | 72 | Select the Arm Linux distribution you are using to find out how to install the 64K page size kernel. |
|
0 commit comments