part 1 getting started
play

Part 1: Getting Started What is next Read mipssim.cc Read - PDF document

11/19/2010 Project 3 Workload vm directory for part 1 is empty Need to come up the design and code Leverage Project 2 experience Project 3 Test C programs provided are sample code and they may contain bugs. Amount of work Tao


  1. 11/19/2010 Project 3 Workload • vm directory for part 1 is empty – Need to come up the design and code – Leverage Project 2 experience Project 3 • Test C programs provided are sample code and they may contain bugs. • Amount of work Tao Yang – Part 1. ~400 lines of code in vm ( few in userprog) – Part 2. ~250 or less in filesys (few in userprog) • Part 1 and 2 can be done in parallel 11/19/2010 2 Project 3 part 2: File system Project 3 part 1: Virtual Memory • Work on vm subdirectory mainly • Work on filesys subdirectoy mainly. – And addrspace.cc/.h and exception.cc in userprog – And change system call handling code in • Create/manage a backing store (a file called SWAP using userprog if needed (to use this extended file the OpenFile class). system). • Implement a page fault handler with dirty bit handling and • Extend the size of each file from 4K to 100K+ a page replacement policy (LRU or second chance) – Few single indirect pointers in i-node. • Design with no implementation for copy-on-write. • Test under various conditions: • Extensible file size (not fixed size). – One process with an address space larger than physical – Can add more than 10 files to the directory memory. (currently the disk directory file is a fixed size – Concurrent processes with combined address space of 10 entries) larger than physical memory. 11/19/2010 3 11/19/2010 4 Part 1: Getting Started What is next • Read mipssim.cc • Read machine/translate.cc: – Machine->ReadMem() is called in executing – In Machine:Translate() for virtual address each instruction. translation, PageFaultException is detected – If PageFaultException is detected, the when the desired page is not in memory. – In Machine:ReadMem, Translate() is called for exception handler should load the desired page. – The hardware will try again. translating the desired virtual memory address and machine->RaiseException() is called with • Need to expand exception.cc to handle PageFaultException error. PageFaultException. – Once handled, return to user mode and restart the instruction caused the fault 1

  2. 11/19/2010 User Instruction Execution Files to be modified for Part 1 Re-execute if Machine:Run () • New files in directory vm Exception is raised OneInstruction () – Virtual memory manager ReadMem () WriteMem () – Swap space manager • Directory userprog (extension to Project 2) – exception.cc Machine:Translate() Page writing? • Extension to handle PageFaultException – Addrspace.cc/.h Set dirty bit Cannot find this page? • Prepare code/data for SWAP backstore. Raise PageFaultException • Virtual address translation -> paging if needed ExceptionHandler() Deal with PageFaultException PageFaultException handling Suggested Class in vm • For a virtual address which is not in • Write a Swap Manager to facilitate free memory, sector allocation in Swap File. – Find free space to host the desired page in – Initialize SWAPSIZE (512) as the total free memory. sector available. • Load the desired page from SWAP to memory. – Allocate a sector. – If no free space available, execute a – Free a sector. replacement policy to find a victim page. • Swap out the victim page. • Swap in the desired page. • Adjust the page table. Suggested Class in vm Modify AddSpace.cc • Virtual memory manager • In translating a virtual user address for kernel, if it is not in memory, bring data from SWAP. – load a page containing the virtual address (copy • When allocating a new address space, from the SWAP file to an allocated memory – Allocate a proper number of sectors from SWAP for page). this process. – Find a victim page – Copy binary data to the allocated SWAP sectors. – Swap out a selected page to SWAP – Initial page number for this process can be 0. 2

  3. 11/19/2010 Design-only task: Copy-on-Write for Synchronization issues Process Forking. • Two system calls may be processed concurrently • Let a child process share the same page as and the synchronization is needed. the parent process if this page is not • Any time a process sleeps in the kernel, another modified by the child process or by the parent process. process can run – two processes try to initiate I/O on the same • During normal process, such a page is read page at the same time only. • May need a lock (or at least a ``busy'' flag) for • During write operation, a each physical memory page, and possibly also for ReadOnlyException is generated and a each virtual memory page . proper action is needed: • Specify program names/files to be modified and what to be added. Part 2: Steps for Nachos file system Files to be modified in Part 2 extension • 1. Understand how the Nachos file system operates and how Directory filesys Nachos implements files. – filehdr.cc/.h Support single indirect pointers in i-node and can expand the file length with more sectors 2. Modify the file system calls from Project 2 to use Nachos allocated. file system – openfile.cc Expand file length/allocate sectors when 3. Modify Nachos file system so that you can create larger writing data at the end or beyond. (100K+) – directory.cc Add more table entries when the current 4. Allow the Write system call to extend the size of a file. table is full and a new file is added. • Directory userprog 5. Support more than 10 files in directory – exception.cc E.g. expand the total no of directory file entries by 10 every time • Make sure that file system calls use extended when a file is added and expansion is needed. Nachos file system. Comparison: Unix file i-node (4K bytes per block) Step 3: Extend maximum file size • Modify the FileHeader i-node to include 4 data sector pointers, and 26 sectors for single indirect mapping. Each of these 26 sectors are a block of pointers – At most map 4 + 26*32=836 blocks. – Maximum file length = 836*128=107008 bytes. • Suggest to add a class called IndirectPointerBlock which takes 1 sector (32 entries) with following operations. – FetchFrom (int sector). WriteBack(int sector). – AddSector (int sector) – add a new sector. – Deallocate(BitMap *freeMap) – deallocate all sectors. – ByteToSector (int offset). – convert an offset in bytes to a sector. 3

  4. 11/19/2010 Step 4: Extensible file Step 4 • Modify WriteAt() method in openfile.cc : • Allow the Write system call to extend the size of a file. – Case 1: Write request is within the bounds of – Currently, if the user tries to write beyond the end of the file, the file. Handle like the existing code Nachos returns an error. – Modify the current implementation so that a write beyond the end – Case 2: Write request overwrites some portion of the file extends the size of the file. of existing file and goes beyond by N bytes. – The exception is that if the file is created to be a given size, your – Case 3: Write request overwrites no data, but implementation should allocate as many sectors (and block pointers) as required to hold that amount of data. goes beyond the end of the file. Here, no data • Gracefully handle the case of the disk being full or needs to be read in. maximum size is reached - the user process should not • Include a routine in FileHeader to extend a crash. Instead an error should be returned. file by N bytes. Testing issues Testing issues in Part 2 • Clean out all the .c files in the code/test directory. There • May need to load user binaries/data into Nachos file might be name conflicts from previous projects system during execution • Get sample test programs in part1 and part2 of the • Example: csil$ pwd ~cs170/nachos-projtest/proj3 directory. cs170/nachos/code/filesys • Test part 1. Test as you would for project 2. You can run csil$ ./nachos -f -cp ../test2/Prog1 Prog1 -x Prog1 the ./nachos in the vm/ or userprog/ directories. You can • Another example with two binary programs use the unix file system for the test. csil$ ./nachos -f -cp ../test2/Prog2 Prog2 -cp ../test2/Prog3/Prog3 -x • Test part 2. It can be convenient to create another test Prog2 directory (e.g. test under test2 directory or fielsys/test) • Notice file names cannot exceed 9 characters. Submission • Writeup a file HW3_WRITEUP I – What is completed. What is not. – Design for each functionality (partial credit for those not working or not implemented) – a separate paragraph on the design and code change necessary to implement the copy-on-write feature.. • Provide a list of test program names and explain what to test with each test program, and your findings for each test. • Also a short note listing times are available/preferred or not available in case Maha needs to meet you. 4

Recommend


More recommend