Page

Tags

comp-arch

Is a block of virtual memory. On Linux each block typically has a page-size/block-size of 4KiB (or \( 2^{12} \) addresses).

The number of pages you need can be found by dividing the number of possible addresses by the size of each page. For a 32-bit system this is \( \frac{2^{32}}{2{12}} = 2^{20} \) pages and for a 64-bit system it's \( \frac{2^{64}}{2{12}} = 2^{52} \) pages.

Pages are required to avoid the overhead of addressing physical memory directly. Consider for example 32-bit machine. In such a machine you have 32-bit pointers which can support \( 2^{32} \) distinct locations, effectively a 4GB address space. Each physical address needs 4 bytes (32-bits) to be stored. To address all 4GB of locations distinctly we'd need 16 billion bytes worth of pointers. In practice it makes more sense to store pointers to pages of a fixed size and then move a certain offset through them to get to the required address. If we need address at 4.2KiB we can store a pointer to the start of the second page and then move 0.2KiB along. This reduces the memory-requirements for translating memory addresses immensely.

Hardware Dependent Bits

Many hardware's and chip-sets may support certain bits to configure how the CPU handles pages. These commonly include:

• Read-only Bit: marks a page as read-only. Attempts to write to it trigger a page fault which will be handled by the kernel. This bit can be useful for loading standard libraries into memory (you wouldn't one process modifying it while others are also using it) or to implement copy-on-write mechanisms for forked processes (the kernel receives the page fault, copies the memory, and reruns the instruction).

• Execution Bit: Determines whether bytes in a page can be executed as CPU instructions. This bit is useful because it prevents stack overflow or code injection attacks when writing user data into the heap or the stack because those are not read-only and thus not executable (See the NX-bit).

  Note: Some processors may merge this and the read-only bit into one, deeming a page as either writable or executable.

• Dirty Bit: Allows a performance optimization by allowing the CPU to skip syncing a page back to the disk if it hasn't changed. Only when the dirty bit is set does the CPU have to write it back to the backing-store.