Autosave: 2024-07-08 07:00:04
This commit is contained in:
parent
aa16fcba7c
commit
9f6e7329fe
4 changed files with 48 additions and 76 deletions
BIN
.zk/notebook.db
BIN
.zk/notebook.db
Binary file not shown.
9
zk/Memory_Management_Unit.md
Normal file
9
zk/Memory_Management_Unit.md
Normal file
|
@ -0,0 +1,9 @@
|
||||||
|
---
|
||||||
|
title: Memory_Management_Unit
|
||||||
|
tags: [memory, Linux]
|
||||||
|
created: Monday, July 08, 2024
|
||||||
|
---
|
||||||
|
|
||||||
|
# Memory_Management_Unit
|
||||||
|
|
||||||
|
## Related notes
|
39
zk/VirtualMemory.md
Normal file
39
zk/VirtualMemory.md
Normal file
|
@ -0,0 +1,39 @@
|
||||||
|
---
|
||||||
|
tags:
|
||||||
|
- memory
|
||||||
|
- Linux
|
||||||
|
---
|
||||||
|
|
||||||
|
# Virtual memory and the Memory Management Unit
|
||||||
|
|
||||||
|
## What is virtual memory?
|
||||||
|
|
||||||
|
Virtual memory is an abstraction of physical memory capacity and allocation that
|
||||||
|
is accessible to user space. The kernel handles physical memory allocation and
|
||||||
|
presents this to user space as a simplified and idealised representation of the
|
||||||
|
available memory of the system.
|
||||||
|
|
||||||
|
The main benefits:
|
||||||
|
|
||||||
|
- User mode processes do not have to be concerned with the physical memory
|
||||||
|
management
|
||||||
|
- There is a buffer between user mode processes and physical memory, meaning
|
||||||
|
that memory cannot be accidentally corrupted by other processes in user space.
|
||||||
|
|
||||||
|
When a process writes or reads from a virtual memory address this does not
|
||||||
|
directly refer to a hardware memory location. The kernel translates this into a
|
||||||
|
physical memory address but this is opaque to the user space process. In fact,
|
||||||
|
the physical memory addresses could be distributed accross multiple
|
||||||
|
non-contiguous locations such as cache and swap memory, not just DRAM.
|
||||||
|
|
||||||
|
Although the physical memory may be distributed and non-contiguous, from the
|
||||||
|
viewpoint of user space, the available virtual memory is contiguous. Each user
|
||||||
|
space process is presented with the same range of available memory addresses and
|
||||||
|
the same total capacity.
|
||||||
|
|
||||||
|
Because this is virtual, there is no risk of one process reading or overwriting
|
||||||
|
the address of another. The same virtual address for multiple programs maps to
|
||||||
|
different physical addresses.
|
||||||
|
|
||||||
|
// Next: more memory offered than is physically available.
|
||||||
|

|
|
@ -1,76 +0,0 @@
|
||||||
---
|
|
||||||
tags:
|
|
||||||
- memory
|
|
||||||
- Linux
|
|
||||||
---
|
|
||||||
|
|
||||||
# Virtual memory and the Memory Management Unit
|
|
||||||
|
|
||||||
## What is virtual memory?
|
|
||||||
|
|
||||||
Virtual memory is implemented at the level of the operating system and is an
|
|
||||||
abstraction on top of 'real', physical memory (i.e the bits stored within the
|
|
||||||
[DRAM](./Memory.md#DRAM).
|
|
||||||
|
|
||||||
When virtual memory is used, the CPU handles physical memory allocation and
|
|
||||||
presents this to the kernel as an idealised representation.
|
|
||||||
|
|
||||||
This means that the kernel ( and, by extension, programs and processes) does not
|
|
||||||
need to think about accessing the real memory blocks.
|
|
||||||
|
|
||||||
This reduces complexity because often memory will be allocated in places that
|
|
||||||
are non-contiguous with similar running processes and may even be located in the
|
|
||||||
cache or in swap memory on the disk, rather than the actual main memory.
|
|
||||||
|
|
||||||
Virtual memory presents a unified abstraction to the kernel over and above these
|
|
||||||
specific memory locations.
|
|
||||||
|
|
||||||
It would require considerable processing work for the kernel to be tracing these
|
|
||||||
disparate memory sources at every instance. By working on an idealised
|
|
||||||
(contiguous, unlimited) memory set the kernel can focus on task management and
|
|
||||||
CPU sequencing as its primary task.
|
|
||||||
|
|
||||||

|
|
||||||
|
|
||||||
The memory is idealised in that all locations are represented virtually as being
|
|
||||||
contiguous (even when this is not physically the case). Secondly, quantities of
|
|
||||||
available memory can be presented as much larger than is actually the case and
|
|
||||||
which often exceed the physical memory limits of the device. This is achieved
|
|
||||||
through paging, handled by the MMU.
|
|
||||||
|
|
||||||
## The Memory Management Unit (MMU)
|
|
||||||
|
|
||||||
Without an MMU, when the CPU accesses RAM, the actual RAM locations never
|
|
||||||
change. The memory address is always the same physical location within the RAM.
|
|
||||||
The MMU is a chip that sits between the CPU and RAM recalculating the actual
|
|
||||||
memory address from the virtual memory location requested by the kernel.
|
|
||||||
|
|
||||||
## 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.
|
|
Loading…
Add table
Reference in a new issue