1. A Simulator to Study Virtual Memory Manager Behavior
My project is a simulator to study virtual memory manager behavior.
Bhuvan Urgaonkar
Robust Software Systems Project Backgrounder Talk

2. Introduction Computer systems employ several resource managers
Our focus: Virtual Memory Manager
Evaluating a VMM
Implement in a real system
Write a simulator
Let me begin with the motivation behind my project. The programs running on a computer system compete for the various resources on the system ie CPU, memory, disk and network bandwidth etc. The system employs resource managers that are responsible for multiplexing these resources among the competitors. Different resource managers employ different policies to achieve this multiplexing depending on the system requirements. An important resource manager is the virtual memory manager. The VMM provides the programs the illusion of more than the physical memory available to them. It does this by transparently making room for the pages that a process needs and that are not in the physical memory by moving some other pages resident in the RAM.
Different types of systems may have different requirements from the VMM and depending on that a VMM may employ different types of page replacement policies. A lot of research has been done and is being done into developing memory managers that improve upon previous ones. So there is a need for mechanisms to evaluate the effectiveness or shortcomings of new solutions for memory management and compare them with existing memory managers. Typically the first step would be to do a theoretical or qualitative comparison of a new solution with existing ones, but beyond that there is a need to conduct experiments to find how the solution actually performs. There can be two principal ways of doing this. One could be to actually implement the memory manager in the kernel or as a user library (?). The second is to build a simulator to do this comparison.

3. Simulator: Motivation
Writing a simulator is easier
Easier to evaluate performance on different environments
Easier to factor out unimportant details
Simulate to see if implementation would be worthwhile
Doing a simulation study of a new proposal for a memory manager has certain advantages. First of all, writing a simulator is easier and faster to do than a real implementation. With a simulator we have the flexibility of studying the performance on machines of varying configurations. This can be achieved by developing the simulator such that it takes machine specific parameters as input. As an example the size of the physical memory can be an input the simulator and then we can study the impact of this parameter on the working of the system. It is easier to factor out components of the system that are not relevant to the particular aspects that we want to study. As an example, when doing a comparative study of two memory managers, we may want to ignore any cache related effects so that we are able to study the impact of solely the memory managers on the performance of programs. Finally simulation can be done to decide if at all it would be worthwhile to go ahead with the more involved task of doing a real implementation.

4. What to Simulate? Simultaneous execution of multiple programs
Resource managers to simulate
VMM, CPU scheduler
Simplifying assumptions
Simple models for disk and NIC
Ignore processor cache
Let me get into more detail of what the simulator is about. In one sentence it would simulate the simultaneous execution of multiple programs on a computer system and produce useful information about the memory reference behavior of the programs. So it will take as input some description of the behavior of the programs that I’ll describe in the next slides, and mimic the execution of these programs under given scheduling policies.
There are two resource managers that we need to simulate in detail. The first is of course the virtual memory manager itself. The other is the CPU scheduler. The working of the scheduler and the memory manager are closely tied to each other. As an example, how often a process gets scheduled may directly affect the number of pages that it is able to get in the RAM. A process that has lots of pages in memory may get to run on the CPU more often than other processes because it doesn’t block as often. So I simulate both these.
For the other resource managers, namely the disk and NIC schedulers, I make a simplifying assumption as a first cut of the simulator. I assume the existence of simple models for these resources that the simulator can use to determine how the requests to these resources would be serviced. As an example, a simple disk model could be to use an average time to service any read requests. I ignore simulating the processor cache to be able to study the VMM’s behavior unaffected by caching effects.

5. Simulator Input/Output
Inputs
Process traces
System specific inputs
Outputs
Per-process allocations with time
Page faults, time spent blocked …
There are two categories of inputs to the simulator. The first are traces that describe the behavior of the processes whose execution we want to simulate and I’ll describe them more in the next slide. The second set of inputs are system specific inputs. These include which memory manager and CPU scheduler are to be simulated, what is the model for the disk or NIC, what is size of the RAM, how big is the virtual address space, what is the length of the CPU quantum is etc.
The outputs that the simulator would produce include how the memory allocated to a process varied with time as the simulation went on. Other outputs include the number of page faults a process incurred, the time it spent blocked on IO, how much of it was spent waiting for page faults to be serviced, how much of it was due to the process’s own behavior, eg due to file reads that it made that caused it to be blocked.

6. Process Traces Memory references Kernel events
Loads and stores
Kernel events
File operations, socket calls
Merge these to obtain a single trace
Obtain per process traces from this
The process traces are obtained as follows. The trace collection is done using a tool called laplace. This tool generates two traces for all the processes that are running. The first trace contains all the memory references ie Load and Store operations and instruction fetches that are performed by the processor. Each of these entries has a time stamp indicating when the reference was made. The second trace is a record of kernel events. The ones that are of interest to us are the operations that may cause a process to block because this would cause the CPU scheduler to be invoked to decide which process to run while this process is blocked.
These two traces are merged to obtain a single trace. This can be done because each of the entries of these traces have a timestamp derived from the CPU cycle counter associated with them.
For our simulator we need a single trace per process containing both the memory references and the kernel calls that the process makes. This trace is obtained by selecting entries corresponding to particular process id from the single trace obtained by merging the reference trace and the kernel trace. Let me show you an example of what a trace would be like.

7. Events to Simulate In the process trace
Load/Store instructions
File/socket calls
Finishing of disk/socket operations
Quantum expiration

8. Implementation PSimJ: A Java simulation library
Three useful abstractions
Processes
Main_body, deactivate, reactivate, delay
Queues
insert, delete, extract
Interrupts
p_interrupt, interrupt routines

9. Implementation (contd.)
Process objects for
Each user process contend for
VMM, CPU scheduler the CPU
Timer, Disk, NIC -- interrupt user processes
Data structures
Bitmap to indicate which pages in RAM
Virtual to physical address mapping
Process run queue and wait queue

10. Data Structures VMM related Scheduler related Other
Bitmap to indicate which pages in RAM
Virtual to physical address mapping
VMM specific: E.g., recency info.
Scheduler related
run queue and wait queue
Other
Per process statistics
There are two main categories of data structures used by the simulator. For the purposes of the memory manager, first there is a bitmap equal to the size of the virtual address space which is used to maintain which pages are currently in RAM. The other DS is to maintain the mapping of virtual to physical addresses to determine where these pages reside in the RAM. Besides these there would be data structures specific to the memory manager being simulated. As an example, if we are simulating a gLRU based memory manager, we would have to maintain access recency information for the pages.
There are two queues that the CPU scheduler uses. The run queue that maintains the currently runnable processes and wait queue that has the processes blocked on IO or a semaphore.
In addition to these the simulator also maintains per process statistics such as a time series of the number of pages allocated to it, the number of page faults it incurred, time spent in the servicing of page faults etc.

11. To Do/Proposed Evaluation
Finish the basic implementation!
Implement Emery/Scott’s VMM
Compare with common VMM’s
I am working on finishing up writing the simulator. Once that is done, I’ll implement a VMM that Emery and Scott Kaplan from Amherst College are working on. This VMM is being designed to be an improvement over existing managers in several ways. Most importantly, it provides processes with a parameter that they can use to specify the degree of memory isolation that they desire from the system. The simulator would then be used to compare this VMM with existing managers.