This is an example of how paging operates on a simplified version of a x86 architecture to implement a virtual memory space with a 20 | 12 address split (4 KiB page size).

The same linear address can translate to different physical addresses for different processes, depending only on the value inside cr3.

Both linear addresses 00002 000 from process 1 and 00004 000 from process 2 point to the same physical address 00003 000. This is completely allowed by the hardware, and it is up to the operating system to handle such cases.

This often in normal operation because of Copy-on-write (COW), which be explained elsewhere.

Such mappings are sometime called "aliases".

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.

Why are pages 4 KiB anyways?

There is a trade-off between memory wasted in:

This can be seen with the extreme cases:

x86 designers have found that 4 KiB pages are a good middle ground.

Name origin: amnion, a pellicle that covers embryos of both eggs and also during pregnancy.

Includes:

Does not include amphibians. If you include them, you have the tetrapods.

Allows us to draw with JavaScript pixel by pixel! Great way to create computational physics demos!

Here is an animation demo with some useful controls:

new class extends OurbigbookCanvasDemo {
  init() {
    super.init('hello');
    this.pixel_size_input = this.addInputAfterEnable(
      'Pixel size',
      {
        'min': 1,
        'type': 'number',
        'value': 1,
      }
    );
  }
  draw() {
    var pixel_size = parseInt(this.pixel_size_input.value);
    for (var x = 0; x < this.width; x += pixel_size) {
      for (var y = 0; y < this.height; y += pixel_size) {
        var b = ((1.0 + Math.sin(this.time * Math.PI / 16)) / 2.0);
        this.ctx.fillStyle =
          'rgba(' +
          (x / this.width) * 255 + ',' +
          (y / this.height) * 255 + ',' +
          b * 255 +
          ',255)'
        ;
        this.ctx.fillRect(x, y, pixel_size, pixel_size);
      }
    }
  }
}

Bibliography: developer.mozilla.org/en-US/docs/Web/API/Canvas_API/Tutorial/Basic_animations">https://developer.mozilla.org/en-US/docs/Web/API/Canvas_API/Tutorial/Basic_animations

After a translation between linear and physical address happens, it is stored on the TLB. For example, a 4 entry TLB starts in the following state:

The > indicates the current entry to be replaced.

And after a page linear address 00003 is translated to a physical address 00005, the TLB becomes:and after a second translation of 00007 to 00009 it becomes:

Now if 00003 needs to be translated again, hardware first looks up the TLB and finds out its address with a single RAM access 00003 --> 00005.

Of course, 00000 is not on the TLB since no valid entry contains 00000 as a key.

The Linux kernel makes extensive usage of the paging features of x86 to allow fast process switches with small data fragmentation.

There are also however some features that the Linux kernel might not use, either because they are only for backwards compatibility, or because the Linux devs didn't feel it was worth it yet.

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:

Ah, the Holy Grail of both biology and computer science!

Ciro Santilli feels it is not for his generation though, and that is one of the philosophical things that saddens him the most in this world.

On the other hand, Ciro's playing with the Linux kernel and other complex software which no single human can every fully understand cheer him up a bit. But still, the high level view, that we can have...

For now, Ciro's 2D reinforcement learning games.

After removing it:

Of course, we already knew that minimal plaster work would be needed from the start, since we have to hammer two small nails into the wall. But that level of damage might have been easily dealt with by a non-professional tenant himself. But the level I had was a bit more than I felt I should handle myself.

By cranks:

Free:

Non-free:

esolangs.org/wiki/Y86 mentions:

One specification at: web.cse.ohio-state.edu/~reeves.92/CSE2421sp13/PracticeProblemsY86.pdf

As of 2020's, it is basically a cheap/slow/simple CPU used in embedded system applications.

See: math.stackexchange.com/questions/579453/real-world-application-of-fourier-series/3729366#3729366

The good:

The bad: