\documentclass{article}

\usepackage{amssymb}
\usepackage{amsmath}

\usepackage{enumerate}
\usepackage{enumitem}

\usepackage{hyperref}
\usepackage{listings}
\usepackage{fontspec}
\newfontfamily\lstlistingfamily[Scale=0.7]{DejaVu Sans Mono}

\usepackage{listings}
\lstset{language=c,
  showstringspaces=false,
  literate={-}{{\texttt{-}}}1{--}{{\texttt{-{}-}}}2{---}{{\texttt{-{}-{}-}}}3,
  basicstyle=\lstlistingfamily
}
\usepackage{mdframed}

\usepackage{makecell}
\usepackage{multirow}
\usepackage{tabularx}
\usepackage[table]{xcolor}

\usepackage{tikz}
\usepackage{multicol}
\usetikzlibrary{arrows,arrows.meta,automata,babel,backgrounds,decorations,backgrounds,positioning,fit}

% compact itemized and then enumerated
\setlist{leftmargin=*,
  noitemsep,
  topsep=5pt,
  parsep=0pt,
  partopsep=0pt,
}

\setlist[enumerate]{leftmargin=*,
  itemsep=2pt,
  topsep=0pt,
  parsep=0pt,
  partopsep=0pt,
}

\begin{document}
\begin{center}
{\Large Operating Systems: Virtual Memory Study Guide}
\end{center}

\noindent\textbf{Three [4] Easy Pieces; Where We Are}
\begin{description}
\item[Persistence] Saving data across computer power cycles;
  \emph{non-volatile} memory can use magnetic or optical media or
  solid-state memory that remembers its state.
\item[\emph{Virtualization}] Emulating part (or all) hardware in
  system software to protect the actual hardware from direct access by
  running software. Can apply to the \emph{processor} and the
  \emph{memory}.
\item[Concurrency] Safely sharing resources across multiple processes
  that are running ``at the same time'', typically by ordering their
  instruction interleaving such that they behave as if they were run
  serially.
\item[Abstraction] Dr. Ladd's \emph{Fourth Easy Piece} The operating
  system provides a facade over heterogeneous hardware, an abstract
  interface that hides the complexity of the underlying systems.
\end{description}

\noindent \textbf{Mechanism} v. \textbf{Policy} --- Remember that
mechanism is \emph{how} the system can do something and policy is
deciding \emph{when} or \emph{why} to do it.

\vspace{3mm}
\hrule{}
\vspace{1mm}

\noindent \textbf{Process Address Space}
\vspace{-3mm}
\begin{multicols}{2}
\noindent
\textbf{Process Segments}

\begin{tikzpicture}
  \tikzstyle{RAMBox} = [right, draw, fill=black!30, minimum height=3cm, minimum width = 1.25cm, anchor=north,rectangle]
  \tikzstyle{SegmentBox} = [right, draw,  fill=white, minimum
  height=0.5cm, minimum width = 1.25cm, anchor=north, rectangle]
  \tikzstyle{StackSegmentBox} = [right, draw,  fill=white, minimum
  height=0.5cm, minimum width = 1.25cm, anchor=south, rectangle]
  \draw (0,0) node[RAMBox, minimum height=8cm] (RAM) {};
  \draw (0,0) node[SegmentBox, minimum width=1.25cm, minimum height=1.cm] (codeSegment) {};
  \draw node [left=of codeSegment] {\texttt{text}};
  \draw node [right=0.25cm of codeSegment.north east,anchor=north west] {\texttt{0x0000}};

  \draw (0,-1.) node[SegmentBox, minimum width=1.25cm, minimum height=1.cm] (dataSegment) {};
  \draw node [left=of dataSegment] {\texttt{data}};
  \draw node [right=0.25cm of dataSegment.north east,anchor=north west] {\texttt{0x0400}};

  \draw (0,-2.) node[SegmentBox, minimum width=1.25cm, minimum height=1.cm] (heapSegment) {};
  \draw node [left=of heapSegment] {\texttt{heap}};
  \draw node [right=0.25cm of heapSegment.north east,anchor=north west] {\texttt{0x0800}};

  \draw node[StackSegmentBox, at=(RAM.south), minimum width=1.25cm, minimum height=1.cm] (stackSegment) {};
  \draw node [left=of stackSegment] {\texttt{stack}};
  \draw node [right=0.25cm of stackSegment.north east,anchor=north west] {\texttt{0xFC00}};
  \draw node [right=0.25cm of stackSegment.south east,anchor=south west] {\texttt{0xFFFF}};
\end{tikzpicture}

\noindent
Addresses assume 64KB address space and exactly 1KB in use by each
segment. Only the \lstinline|heap| and \lstinline{stack} are typically
permitted to grow dynamically, hence the free space between them.

\noindent
\textbf{Question:} Which segment(s) grow from lower-to-higher memory
addresses? Which grow the opposite direction?

\noindent
\textbf{Segment Usage}
\begin{description}[font=\ttfamily]
\item[text] the \emph{code} segment containing the machine
  instructions translated by the compiler, linked together with
  libraries by the linker, and loaded into the ``right'' place by the
  loader.
\item[data] static/global data segment. In addition to global
  variables, string and composite literals, translated by the
  compiler, end up here.
\item[heap] dynamically allocated memory; where \lstinline|new| gets
  its data.
\item[stack] dynamic allocation of local variables for function calls;
  the stack is made up of \emph{activation records}, one for each
  currently active function.
\end{description}

\noindent
\textbf{Question:} Which segment(s) are loaded from the \emph{program
  file} (statically)? Which segment(s) have their contend generated
purely dynamically?
\end{multicols}


\vspace{3mm}
\hrule{}
\vspace{1mm}
\noindent \textbf{Memory Translation}

\noindent \textbf{Address Spaces}
\begin{description}
\item[Virtual] The \textbf{process} address space. \emph{Always} runs
  across the exact same range (\emph{i.e.} \lstinline|0x00000000| -
  \lstinline|0xFFFFFFFF|). Permits the compiler/linker to ignore
  location in \emph{physical} address space.
\item[Physical] The \textbf{hardware} (and \textbf{operating system})
  address space. Runs from the first byte in a \textbf{RAM} chip to
  the last byte in the installed memory. Addresses also start from 0
  and count up, by byte.
\end{description}

\noindent \textbf{Loading Policies}
\begin{description}
\item[Singleton] Load exactly one process at a time, into address
  \lstinline|0x00000000|. \emph{Pros:} no address translation, no CPU
  modification, easy compilation; \emph{Cons:} maximum of one running
  process.
\item[Static Relocation] Let the compiler target \emph{some} range of
  physical memory when executable is created. Load the program into
  that location. Multiple programs, with non-overlapping address
  usage, can share the physical address space. \emph{Pros:} no address
  translation and no CPU mods; \emph{Cons:} each process has a single
  place to load or must be recompiled (or stored multiple times).
\item[Dynamic Relocation] OS \textbf{transparently} translates
  addresses based on where the process was loaded. \emph{Pros:} easy
  compiling, can load one executable into any available memory,
  multiple processes in memory simultaneously; \emph{Cons:} need
  base/bounds (or similar) registers [\textbf{Hardware Assist}], each
  memory access is translated (and bounds checked), dynamic memory
  management in the OS, must allocate all process memory contiguously.
\item[Segmentation] Multiply the base/bounds concept by having a
  base/bounds per process \emph{segment}. \emph{Pros:} easier to fit
  into fragmented memory, uses existing link specification;
  \emph{Cons:} more registers (this is context).
\item[Paging] Allocate all memory in small, identically sized blocks
  (\emph{pages} of virtual memory into \emph{frames} of physical
  memory). \emph{Pros:} no need to track size of allocation, no need
  to find contiguous blocks of RAM, can be swapped out to secondary
  storage (because of one size this is easier), no need to load entire
  segments into memory; \emph{Cons:} too many registers (need a
  \emph{page table} per process that is stored in RAM), bookkeeping on
  what frames to free on a page fault is non-trivial.
\end{description}

Paging and segmentation can be combined.

\vspace{3mm}
\hrule{}
\vspace{1mm}
\noindent \textbf{Paging}

A \emph{page table entry} (PTE) contains \emph{metadata} about the
page and the \emph{frame} address where it is (if it is in memory) or
the \emph{swap} address where it is if the OS has swapped it out.

\emph{Metadata} can include the \emph{valid} bit (is this page a
proper part of the process's address space), the \emph{present} bit
(is this page resident in memory), the \emph{dirty} bit (has this page
changed since it was loaded), and the \emph{reference} bit (has this
page been accessed by the process since the OS reset reference
bits). The address field in the PTE can contain a \emph{frame number}
(if page is \emph{present}), a \emph{swap page number} if the page was
evicted to the swap, or (effectively) \lstinline|null|. The size of
the PTE is determined by taking the number of bits of address, adding
the number of bits of metadata, and rounding up to the next byte size.


The \emph{page table} is an array of PTE. There is one PTE per page in
the \emph{process address space}. The size of the page table is the
product of the number of PTE and the size, in bytes, of each PTE. The
context of the process includes a \emph{page table base register}
(PTBR), the  physical address of the beginning of the page table.

To translate an address: Split address into page number (\textbf{P})
and offset into page (\textbf{o}).  Use \textbf{P} and size of PTE to
calculate array offset into page table of proper PTE. Add array offset to
PTBR and fetch PTE. Assuming no page fault, extract frame number from
PTE (\textbf{F}) and prepend \textbf{F} to \textbf{o} to get physical
address.

On page fault (page not present): OS figures out where data for the
page lives: in the program file (if it is part of the immutable
\lstinline|text| or \lstinline|data| segments), in swap (if it is a
mutable page that had been allocated earlier), or should be newly
allocated (it is in the free space between segments). If it is on
disk, schedule the read and block the process on the completion. If it
is a new allocation, grab a frame, zero, and update the PTE (into page
table).

Once page contents are read, pick a victim frame and put the data in
it. Update PTE for this process and unblock it and also update page
table of process from which the frame was taken. Once page is full and
PTE updated, make process ready and it will restart the instruction.

\emph{Victim} is selected by some policy. One good one is
\emph{least-recently used} (LRU).


\vspace{3mm}
\hrule{}
\vspace{1mm}

\noindent
\textbf{Question:} The table below describes a \emph{paged} memory system. Fill in
the empty boxes to complete the description and answer the questions
following the table.


  \begin{footnotesize}
    \begin{sffamily}
\vspace{1mm}
      \begin{tabular}{|l|l|l|l|}
        \hline
        \multicolumn{4}{|c|}{Metadata (b)}\\
        \hline
        valid&present&dirty&reference\\
        \hline
      \end{tabular}
\vspace{1mm}

      \begin{tabular}{c|c|c|c|c|c|c|c|c|}
        &     &&          &&&Bit Width&Page Table\\
        &Address Space&Bit Width&Page/Frame&Bit Width&Number of&Page/Frame&Entry Size\\
        &Size (B)&Address&Size (B)&Offset&Pages/Frames&Number&in Bytes \\
        \hline
        Virtual&1M&&&&&&\\
        \hline
        Physical&32M&&4K&&&\multicolumn{1}{c}{}\\
        \cline{1-6}
      \end{tabular}
    \end{sffamily}
  \end{footnotesize}
  \vspace{1mm}

  \begin{enumerate}[label=\alph*.]
  \item Explain why the number of bits in the \emph{page numbers}
  and the number of bits in the \emph{frame numbers} \textbf{are/are
    not} the same.

\item How \textbf{many} entries in a \emph{page table}?
\item \textbf{Size} (B) of \emph{page table}?


\noindent
Process Q's page table is in memory beginning at \texttt{0x1000}.
The process's page table begins with the following entries (spaced
as closely together as possible on whole byte boundaries); all
numbers are in hex.
\newpage
\begin{multicols}{2}
  \begin{tabular}{ll}
    \multicolumn{2}{c}{\textbf{Page Table}}\\
    Meta&Frame\\\hline
    \texttt{3}&\texttt{000}\\
    \texttt{C}&\texttt{0F0}\\
    \texttt{A}&\texttt{00E}\\
    \texttt{E}&\texttt{D00}\\
    \texttt{E}&\texttt{0CC}\\
    \texttt{F}&\texttt{B0B}\\
    \texttt{B}&\texttt{AA0}\\
  \end{tabular}
  \vspace{5mm}

\begin{lstlisting}
03FF8       movl  0x05010, %eax
        top:
03FFC       cmpl  $0x21, %eax
04000       jg     bottom
04004       movl  0x05010, %eax
04008       addl  $0x01, %eax
0400C       movl  %eax, 0x05010
04010       jmp   top
     bottom:
04014
\end{lstlisting}

\end{multicols}

\noindent
Initially \lstinline|RAM[0x05010] == 0|.
  \vspace{1mm}

\item Which \emph{pages} are invalid?
  \vspace{1mm}


\noindent
On our computer, each instruction takes exactly one (1) clock
cycle. Consider the following code:

\item Give the \emph{virtual} address trace for 12 clock
  cycles of this code.

  \item Using the page table given above, give the
    corresponding \emph{physical} address trace.
\end{enumerate}

\vspace{3mm}
\hrule{}
\vspace{1mm}
\noindent \textbf{User Memory Allocation}
\lstinline|malloc| is part of the C Runtime-Library (CRT).

One way of keeping track of free memory is with a \emph{free list}: a
linked list where each node is a block (of variable size) with two
fields placed at the beginning of the block: \lstinline|size| and
\lstinline|next|. \lstinline|size| is the size, in bytes, of this node
and \lstinline|next| is the address of the next node in the free list.

\noindent
\textbf{Question:} Is \lstinline|next| a \emph{physical} or a
\emph{virtual} address?

Allocation is done by traversing the free list for a node large enough
to service the \lstinline|malloc| call, along with any bookkeeping
fields. Consider the \textbf{best-fit}, \textbf{first-fit}, and
\textbf{worst-fit} policies for allocating memory.

\noindent
\textbf{Question:} Describe \emph{internal} and \emph{external}
fragmentation in terms of \lstinline|malloc| that allocates only 1KB and
2KB blocks. What could possibly go wrong?
\begin{enumerate}[label=\alph*.]
\item When could \emph{internal} fragmentation cause there to be
  enough ``free'' memory to exist for a 1.5KB allocation yet the
  system be unable to fulfill it?
\item When could \emph{external} fragmentation cause there to be
  enough ``free'' memory to exist for a 1.5KB allocation yet the
  system be unable to fulfill it?
\end{enumerate}

\end{document}

%%% Local Variables:
%%% mode: latex
%%% TeX-master: t
%%% End:
