Tidy up

docs/lectures/osc/09_mem_management1.md

@@ -4,10 +4,10 @@
 
 Computers typically have memory hierarchies:
 
-> * Registers
-> * L1/L2/L3 cache
-> * Main memory (RAM)
-> * Disks
+> - Registers
+> - L1/L2/L3 cache
+> - Main memory (RAM)
+> - Disks
 
 **Higher Memory** is faster, more expensive and volatile. **Lower Memory** is slower, cheaper and non-volatile.
 
@@ -15,15 +15,13 @@ The operating system provides **memory abstraction** for the user. Otherwise mem
 
 ### OS Responsibilities
 
-* Allocate/de-allocate memory when requested by processes, keep track of all used/unused memory.
-* Distribute memory between processes and simulate an **indefinitely large** memory space. The OS must create the illusion of having infinite main memory, processes assume they have access to all main memory.
-* **Control access** when multi programming is applied.
-* **Transparently** move data from **memory** to **disk** and vice versa.
+- Allocate/deallocate memory when requested by processes and keep track of all used/unused memory.
+- Distribute memory between processes and simulate an **indefinitely large** memory space. The OS must create the illusion of having infinite main memory. Processes assume they have access to all main memory.
+- **Control access** when multi-programming is applied.
+- **Transparently** move data from **memory** to **disk** and vice versa.
 
 #### Partitioning
 
-![img](assets/A.png)
-
 ##### Contiguous memory management
 
 Allocates memory in **one single block** without any holes or gaps.
@@ -36,48 +34,44 @@ Where memory is allocated in multiple blocks, or segments, which may not be plac
 
 **Multi-programming** with **fixed partitions**
 
-* Fixed  **equal** sized partitions
-* Fixed non-equal sized partitions
+- Fixed **equal-sized** partitions
+- Fixed non-equal-sized partitions
 
 **Multi-programming** with **dynamic partitions**
 
 #### Mono-programming
 
-> * Only one single user process is in memory/executed at any point in time.
-> * A fixed region of memory is allocated to the OS & kernal, the remaining memory is reserved for a single process
-> * This process has direct access to physical memory (no address translation takes place)
-> * Every process is allocated **contiguous block memory** (no holes or gaps)
-> * One process is allocated the **entire memory space** and the process is always located in the same address space.
-> * **No protection** between different user processes required. Also no protection between the running process and the OS, so sometimes that process can access pieces of the OS its not meant to.
+> - Only one single user process is in memory/executed at any point in time.
+> - A fixed region of memory is allocated to the OS and kernel. The remaining memory is reserved for a single process
+> - This process has direct access to physical memory (no address translation takes place)
+> - Every process is allocated **a contiguous block of memory** (no holes or gaps)
+> - One process is allocated the **entire memory space** and the process is always located in the same address space.
+> - **No protection** between different user processes is required. There is also no protection between the running process and the OS, so sometimes that process can access pieces of the OS it's not meant to.
 >
-> * Overlays enable the **programmer** to use **more memory than available**.
+> - Overlays enable the **programmer** to use **more memory than available**.
 
-![img](assets/B.png)
+##### Shortcomings of Mono-Programming
 
-##### Short comings of mono-programming
+> - Since a process has direct access to the physical memory, it may have access to the OS memory.
+> - The OS can be seen as a process - so we have **two processes anyway**.
+> - **Low utilisation** of hardware resources (CPU, I/O devices etc)
+> - Mono-programming is unacceptable as **multi-programming is expected** on modern machines
 
-> * Since a process has direct access to the physical memory, it may have access to the OS memory.
-> * The OS can be seen as a process - so we have **two processes anyway**.
-> * **Low utilisation** of hardware resources (CPU, I/O devices etc)
-> * Mono-programming is unacceptable as **multi-programming is excepted** on modern machines
-
-**Direct memory access** and **mono-programming** are common in basic embedded systems and modern consumer electronics eg washing machines, microwaves, cars etc.
+**Direct memory access** and **mono-programming** are common in basic embedded systems and modern consumer electronics, e.g. washing machines, microwaves and cars.
 
 ##### Simulating Multi-Programming
 
 We can simulate multi-programming through **swapping**
 
-* **Swap process** out to the disk and load a new one (context switches would become **time consuming**)
+- **Swap process** out to the disk and load a new one (context switches would become **time consuming**)
 
 Why Multi-Programming is better theoretically
 
-> * There are *n* **processes in memory**
-> * A process spends *p* percent of its time **waiting for I/O**
-> * **CPU Utilisation** is calculated as 1 minus the time that all processes are waiting for I/O
-> * The probability that **all** *n* **processes are waitying for I/O is *p*^n^ 
-> * Therefore CPU utilisation is given by $1 - p^{n}$ 
-
-![cpu_util_form](assets/C.png)
+> - There are *n* **processes in memory**
+> - A process spends *p* percent of its time **waiting for I/O**
+> - **CPU Utilisation** is calculated as 1 minus the time that all processes are waiting for I/O
+> - The probability that **all** *n* **processes are waiting for I/O** is $p^{n}$
+> - Therefore CPU utilisation is given by $1 - p^{n}$
 
 With an **I/O wait time of 20%** almost **100% CPU utilisation** can be achieved with four processes             ($1-0.2^{4}$)
 
@@ -89,49 +83,47 @@ CPU utilisation **goes up** with the **number of processes** and **down** for **
 
 **Assume that**:
 
-> * A computer has one megabyte of memory
-> * The OS takes up 200k, leaving room for four 200k processes
+> - A computer has one megabyte of memory
+> - The OS takes up 200k, leaving room for four 200k processes
 
 **Then:**
 
-> * If we have an I/O wait time of 80%, then we will achieve just under 60% CPU utilisation (1-0.8^4^)
-> * If we add another megabyte of memory, it would allow us to run another five processes. We can now achieve about **87%** CPU utilisation (1-0.8^9^)
-> * If we add another megabyte of memory (14 processes) we find that CPU utilisation will increase to around **96%**
+> - If we have an I/O wait time of 80%, then we will achieve just under 60% CPU utilisation ($1-0.8^{4}$)
+> - If we add another megabyte of memory, it would allow us to run another five processes. We can now achieve about **87%** CPU utilisation ($1-0.8^{9}$)
+> - If we add another megabyte of memory (14 processes) we find that CPU utilisation will increase to around **96%**
 
 ##### Caveats
 
-* This model assumes that all processes are independent, this is not true.
-* More complex models could be built using **queuing theory** but we still use this simplistic model to make **approximate predictions**
+- This model assumes that all processes are independent. This is not true.
+- More complex models could be built using **queuing theory** but we still use this simplistic model to make **approximate predictions**
 
 #### Fixed Size Partitions
 
-* Divide memory into **static**, **contiguous** and **equal sized** partitions that have a fixed **size and location**.
-  * Any process can take **any** partition. (as long as its large enough)
-  * Allocation of **fixed equal sized partitions to processes is trivial**
-  * Very **little overhead** and **simple implementation**
-  * The OS keeps a track of which partitions are being **used** and which are **free**.
+- Divide memory into **static**, **contiguous** and **equal sized** partitions that have a fixed **size and location**.
+    - Any process can take **any** partition (as long as it's large enough)
+    - Allocation of **fixed equal sized partitions to processes is trivial**
+    - Very **little overhead** and **simple implementation**
+    - The OS keeps track of which partitions are being **used** and which are **free**.
 
 ##### Disadvantages
 
-* Partition may be necessarily large
-  * Low memory utilisation
-  * Internal fragmentation
-* **Overlays** must be used if a program does not fit into a partition (burden on the programmer)
+- Partition may be necessarily large
+    - Low memory utilisation
+    - Internal fragmentation
+- **Overlays** must be used if a program does not fit into a partition (burden on the programmer)
 
 #### Fixed Partitions of non-equal size
 
-* Divide memory into **static** and **non-equal sized partitions** that have **fixed size and location**
-  * Reduces **internal fragmentation**
-  * The **allocation** of processes to partitions must be **carefully considered**.
-
-![process_alloc](assets/E.png)
+- Divide memory into **static** and **non-equal sized partitions** that have **fixed size and location**
+    - Reduces **internal fragmentation**
+    - The **allocation** of processes to partitions must be **carefully considered**.
 
 **One private queue per partition**:
 
-* Assigns each process to the smallest partition that it would fit in.
-* Reduces **internal fragmentation**.
-* Can reduce memory utilisation (e.g. lots of small jobs result in unused large partitions)
+- Assigns each process to the smallest partition that it would fit in.
+- Reduces **internal fragmentation**.
+- Can reduce memory utilisation (e.g. lots of small jobs result in unused large partitions)
 
 **A single shared queue:**
 
-* Increased internal fragmentation as small processes are allocated into big partitions.
+- Increased internal fragmentation as small processes are allocated into big partitions.