The exact format of table entries is fixed _by the hardware_.

Each page entry can be seen as a struct with many fields.

The page table is then an array of struct.

On this simplified example, the page table entries contain only two fields:so in this example the hardware designers could have chosen the size of the page table to b 21 instead of 32 as we've used so far.

All real page table entries have other fields, notably fields to set pages to read-only for Copy-on-write. This will be explained elsewhere.

It would be impractical to align things at 21 bits since memory is addressable by bytes and not bits. Therefore, even in only 21 bits are needed in this case, hardware designers would probably choose 32 to make access faster, and just reserve bits the remaining bits for later usage. The actual value on x86 is 32 bits.

Here is a screenshot from the Intel manual image "Formats of CR3 and Paging-Structure Entries with 32-Bit Paging" showing the structure of a page table in all its glory: Figure 1. "x86 page entry format".

The fields are explained in the manual just after.

The problem with a single-level paging scheme is that it would take up too much RAM: 4G / 4K = 1M entries _per_ process.

If each entry is 4 bytes long, that would make 4M _per process_, which is too much even for a desktop computer: ps -A | wc -l says that I am running 244 processes right now, so that would take around 1GB of my RAM!

For this reason, x86 developers decided to use a multi-level scheme that reduces RAM usage.

The downside of this system is that is has a slightly higher access time, as we need to access RAM more times for each translation.

Learned readers will ask themselves: so why use an unbalanced tree instead of balanced one, which offers better asymptotic times en.wikipedia.org/wiki/Self-balancing_binary_search_tree?

Likely:

If either PAE and PSE are active, different paging level schemes are used:

Using the TLB makes translation faster, because the initial translation takes one access _per TLB level_, which means 2 on a simple 32 bit scheme, but 3 or 4 on 64 bit architectures.

The TLB is usually implemented as an expensive type of RAM called content-addressable memory (CAM). CAM implements an associative map on hardware, that is, a structure that given a key (linear address), retrieves a value.

Mappings could also be implemented on RAM addresses, but CAM mappings may required much less entries than a RAM mapping.

For example, a map in which:could be stored in a TLB with 4 entries:

linear  physical
------  --------
00000   00001
00001   00010
00010   00011
FFFFF   00000

However, to implement this with RAM, _it would be necessary to have 2^20 addresses_:which would be even more expensive than using a TLB.

Convert virtual addresses to physical from user space with /proc/<pid>/pagemap and from kernel space with virt_to_phys:

Dump all page tables from userspace with /proc/<pid>/maps and /proc/<pid>/pagemap:

Read and write physical addresses from userspace with /dev/mem:

The Linux Kernel reserves two zones of virtual memory:

The exact split is configured by CONFIG_VMSPLIT_.... By default:

Kernel memory is also paged.

In previous versions, the paging was continuous, but with HIGHMEM this changed.

There is no clear physical memory split: stackoverflow.com/questions/30471742/physical-memory-userspace-kernel-split-on-linux-x86-64

The first chapter of the New Testament.

Information about ARM paging can be found at: cirosantilli.com/linux-kernel-module-cheat#arm-paging

Free:

Non-free:

The first thing you must understand is the Classic RISC pipeline with a concrete example.

The good:

The bad:

Equation "Hydrogen spectral series mnemonic" gives for example from principal quantum number 1 to 2 a difference:which with Planck-Einstein relation gives about 121.6 nm ($2.47\times 10^{1}5$ Hz), which is a reasonable match with the value of 121.567... from the NIST Atomic Spectra Database.

Was a closed source project by "Roboti LLC", which was then acquired by DeepMind in October 2021 and open sourced March 2022: www.deepmind.com/blog/open-sourcing-mujoco

This library is quite cool. Feel very brutally lean and mean.

The good:

The bad: