Autosave: 2024-07-16 17:00:03

This commit is contained in:
thomasabishop 2024-07-16 17:00:03 +01:00
parent 32c915a652
commit 07f3694003
3 changed files with 59 additions and 8 deletions

Binary file not shown.

View file

@ -4,6 +4,41 @@ tags: [memory, Linux]
created: Monday, July 08, 2024
---
# Memory_Management_Unit
# Memory Management Unit (MMU)
## Related notes
The MMU is the bridge between the physical memory devices of the machine and the
virtual memory space. It is a chip that sits between the CPU and the RAM and
determines the physical location of the memory requested by the kernel as
virtual memory.
![Virtual memory diagram](/img/virtual-memory-diagram.jpg)
## Pages
We use the term **pages** to denote blocks of virtual memory and to distinguish
them from **addresses** as physical blocks. The MMU possesses a **page table**
which is registry logging which pages correspond to which physical blocks.
## Shared pages
Virtual memory allows the sharing of files and memory by multiple processes.
Crucially the shared data doesn't have to be within the address of each process,
instead there is a reference in the page table that each process has access to
the shared data.
## Page faults
There are two kinds of error that can occur with relation to paged memory:
- minor page faults
- The desired page is in main memory but the MMU doesn't currently know where
it is
- major page faults
- The desired page is not in main memory at all. Therefore the kernel must
fetch it from disk
Minor page faults are very common and are to be expected; they resolve quickly.
On the other hand too many major page faults can slow the system down both
because of the time-costly process of fetching data from disk and because it
demands more kernel resources to locate the missing page, which puts other
processes on hold.

View file

@ -45,17 +45,33 @@ _How Computers Really Work_ (2021) p.206
## Virtual memory and the kernel
The kernel itself utilises virtual memory. The kernel virtual memory has a
different range of virtual addresses to work with than user space virtual
memory.
The kernel itself utilises virtual memory.
During the [boot_process](Boot_process.md), it runs in physical memory mode
however it rapidly creates a 1:1 mapping of physical to virtual memory for
itself. This direct mapping allows the kernel to easily access any physical
memory location as needed, whilst retaining the benefits of virtual memory.
With its own virtual memory established, it can then build additional virtual
memory structures for itself and user processes.
While the kernel uses virtual memory it can also access physical memory at any
time wherease user space processes can only ever access virtual memory.
The kernel virtual memory has a different range of virtual addresses to work
with than user space virtual memory.
Unlike user space virtual memory, the kernel has access to everything running in
kernel address space whereas processes in user address space are partitioned
from each other with separate address spaces that cannot interact.
// Next: the kernel also uses virtual memory however isn't also responsible for
the appportioning of virtual memory. Confused.
In addition to being able to access its own virtual memory (and physical memory,
as required) the kernel can also access any user processes' virtual address.
// See Claude convo
This said, the virtual memory space of the kernel and the virtual memory space
of the user processes are distinct. It is not the case that the kernel is
superset of all available virtual memory. It can access user space virtual
memory because it sets up the tables and locations, not because it is a subset
of its own virtual memory.
![Virtual memory diagram](/img/virtual-memory-diagram.jpg)