lec 9 notes done
authorKyle Spaans <kspaans@student.math.uwaterloo.ca>
Wed, 3 Jun 2009 00:02:14 +0000 (20:02 -0400)
committerKyle Spaans <kspaans@student.math.uwaterloo.ca>
Wed, 3 Jun 2009 00:02:14 +0000 (20:02 -0400)
lec09-0602.tex [new file with mode: 0644]

diff --git a/lec09-0602.tex b/lec09-0602.tex
new file mode 100644 (file)
index 0000000..6297fb2
--- /dev/null
@@ -0,0 +1,68 @@
+\documentclass{article}
+\usepackage{fullpage}
+\usepackage{amsmath}
+\author{Kyle Spaans}
+\date{June 2, 2009}
+\title{Operating Systems Lecture Notes}
+\begin{document}
+\maketitle
+
+\section*{Lecture 9 -- Processes}
+Remember that context switches will only occur while we are executing kernel
+code, I.E. after the exception handler has been called. This is how the kernel
+preempts threads. So the order is roughly \textsf{Interrupt $\to$ trap
+frame $\to$ mips\_syscall() $\to$ Kernel Code} with preemption
+happening potentially somewhere inside the exception handling. We are free to
+change choices like these, since we can modify the scheduler whenever we want.
+
+\subsection*{Processes}
+\emph{OS161} currently only supports sequential processes, so process
+implentation details can be put into the thread structure. We can see this in
+the address space and current working directory pointers.
+
+There are system calls for managing processes, such as \texttt{fork()} and
+\texttt{execv()}, as well as other for exiting from processes or getting a
+process' identifier. For assignment 2 we will be implementing processes. Some
+of the choices we'll be faced with are: how are processes initialized, how can
+processes have more than one thread, what are the relationships between
+processes (parent/child) and what do they mean, and how can processes
+communicate?
+
+\subsection*{Virtual Memory}
+Processes each have their own, seperate address spaces. Hardware, such as the
+MMU, helps to translate the virtual addresses that userspace (process) code
+uses into physical addresses that correspond to real hardware. The hardware
+will also arbitrate access to memory; it will throw exceptions if a program
+reads or writes to the wrong parts of memory, or for a variety of other reasons
+that we'll see soon. There are different schemes for managing virtual memory.
+In the real world, a combination of these is usually used.
+
+\paragraph*{Dynamic Relocation}
+Virtual addresses spaces are made up of varying sized, contiguously allocated
+chunks of physical memory. The physical address is built from a relocation
+address (can be stored in a special ``relocation register'') plus the offset
+within the address space, which is the virtual address. So each virtual address
+space starts at 0 and is uniquely identified by it's relocation address. These
+chunks have a size that can change as well. This scheme can lead to 
+\textbf{external fragmentation}, where physical memory has unsable gaps between
+virtual address space chunks. It's hard to fix because moving the virtual space
+to a new physical location is tricky and slow (loading and storing each word
+explicitly).
+
+\paragraph*{Paging}
+The hardware sets a physical page size (always a multiple of 2, for speed
+reasons), 4KB in the case of MIPS. Virtual address space is split into
+pages, which are directly mapped to physical ``frames''. Each process has
+an associated page table to map virtual addresses to physical ones. The
+virtual address has an offset and a page number, and a Page Table Entry
+specifies a frame that corresponds to the page. The PTE can also have some
+flag bits, to mark pages as read-only, executable, dirty, etc. A special
+register holds the address of the page table. Notice that this is more overhead
+than the dynamic relocation scheme. The kernel must manage the page table. This
+leads to \textbf{internal fragmentation} where we lose memory at the end of
+every unfilled page. A page number can be calculated using ($V$ is the virtual
+address)
+\[ \left\lfloor \frac{V}{\mathrm{page size}} \right\rfloor \] 
+and offset is $V \bmod \mathrm{page size}$.
+
+\end{document}