Introduction
#include
#include
struct node
{
int page;
int t_num;
struct node next;
};
struct list
{
int size;
int count;
struct node list;
}TLB,Memory;
void flush()
{
struct node p=TLB.list;
struct node q;
TLB.count=0;
while(p!=NULL)
{
q=p->next;
free(p);
p=q;
}
TLB.list=NULL;
}
struct trace
{
int hit;
int pf;
int pageout;
int avs;
int vs;
int is_over;
long total;
long index;
char fname;
FILE fin;
};
Makefile .c
Requirement
CMPUT 379, Assignment 3, Winter 2017
(Topics: paging, MMU, TLB, virtual memory)
Objective
You will implement a simulator to study the TLB behavior. and the page eviction
policy of a virtual memory subsystem. A number of traces of 32-bit memory
references are read and the TLB evictions and the virtual memory page-in page-
out eviction activity is monitored. At the end of execution, relevant performance
metrics are produced.
The command line invocation
The simulator is invoked as follows:
tvm379 pgsize tlbentries { g | p } quantum physpages { f | l } trace1 trace2 …
tracen
Where pgsize is the page size (always a power of 2 from 16 to 65,536), tlbentries are
the number of simulated TLB entries (always a power of 2 from 8 to 256), followed
by a single letter indication whether the TLB is uniform. across processes ( g i.e.,
“global” in which case the TLB entries include an identifier of the corresponding
process) or if they cannot distinguish across processes ( p i.e., “process” specific).
If the TLB entries do not include an address space identifier to distinguish
processes, that is, if they are p , then the TLB entries need to be “flushed” every
time we have a context switch. Note that the TLB eviction policy is strictly
LRU. The context switch is simulated by going through the trace of references
(see below) reading quantum memory references at a time from each file in a
cyclical (round robin) order.
The virtual memory aspect of the system is simulated by assuming that we
are implementing a global page replacement policy (check your textbook and
notes for the definition) where the available physical memory is assumed to be
physpages (up to 1,000,000) and where the page eviction policy is FIFO ( f ) or
LRU (l).
Input file processing
The program must be able to receive as input a variable number of trace files
(trace1 trace2 … tracen). Each of them contains (in binary form, each entry
occupying four bytes, most significant byte first) a sequence of 32-bit memory
reference. The files can be significantly long, so it is prudent to avoid reading in
their entire contents before processing. In fact it is required that you read them
incrementally, as needed.
1
The simulated memory management unit sees the memory references arriving
quantum at a time, rotating from each file. For example, if we have three trace
files, and the quantum is 100, then the input is processed in this order: entries
1-100 from trace1 are read/processed, followed by entries 1-100 from trace2,
followed by entries 1-100 from trace3, followed by entries 101-200 from trace1,
followed by entries 101-200 from trace2 etc. Effectively, you simulate the MMU
behavior. as if a context switch occurs every quantum memory references.
Note that the traceX files do not contain any information as to whether the
access to the memory location is read or write and what values are read or
written there.
Output
Upon termination your program should produce lines consisting solely of integers
of the following form. to stdout :
tlbhits1 pf1 pageout1 avs1
tlbhits2 pf2 pageout2 avs2
…
tlbhitsn pfn pageoutn avsn
These are n lines, as many as the trace files given in the command line. tlbhitsX
is the number of TLB hits because of memory references from traceX. pfX is
the number of page faults caused by the memory references of traceX i.e., of
“process” X. Note that, this being a global page replacement policy, the processes
whose behavior. caused a page fault (and therefore for which we increased the
corresponding pfX) is not necessarily the process whose page will be victimized.
Hence, you also have to increment the number of evicted pages pageoutX incurred
by process X when a page of process X is victimized. Finally avsX is the average
number of memory-resident pages for process X across the entire simulation
time. This is because, again due to the global page replacement policy, the mix
of pages in physical memory on behalf of each process varies over time. The
avsX reports what was the average of the in-memory pages where the averaging
takes place over the complete number of references processed by the simulation
from beginning to end of simulation.
Additional Information
In the labs we will demonstrate simple ways to obtain the memory access
trace files. Note that, the trace files may not have the exact same length and
one process trace file may therefore “terminate” earlier than the rest. This is
acceptable and should not cause your program to fail in any way.
2
Deliverables
The language of implementation is C
Your assignment should be submitted as a single compressed archive file. The
archive should contain all necessary source files as well as a Makefile . Call-
ing make without any arguments should generate the tvm379 executable. One
item that must accompany your submission is a brief documentation (can
be a single README.txt file) of how you ensured that your simulation
(through the choice of particular data structures for example) is ef-
ficient and scalable pointing to relevent points in your source code .
You are expected to deliver good quality, efficient, code. That is, the quality
and performance of your code will be taken into consideration when
marking.
IMPORTANT: if you plan to use github for collaboration with your
group mate, please ensure you are using a private repository. The
submission page will include a declaration through which you will
be confirming that you did not use methods that allowed your code
(even if in development stages) to be publicly accessible.
Friday, March 17, 2017