CMPUT 379, Assignment 3 IT 代写
						  100%原创包过,高质代写&免费提供Turnitin报告--24小时客服QQ&微信:120591129
						
					
	CMPUT 379, Assignment 3 IT 代写
	
	
	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
	3
	
	CMPUT 379, Assignment 3 IT 代写