From 4bd5cb5f9e4778ceed3737e3c8f7f6fa1cf0b3f1 Mon Sep 17 00:00:00 2001 From: Karoline Knoth Date: Thu, 21 Jun 2012 14:57:17 +0200 Subject: answers to design doc of proj2 --- proj2.txt | 34 ++++++++++++++++++++++++++++------ 1 file changed, 28 insertions(+), 6 deletions(-) diff --git a/proj2.txt b/proj2.txt index 5405336..3b89826 100644 --- a/proj2.txt +++ b/proj2.txt @@ -30,7 +30,7 @@ Manuel Mausz >> enumeration. Identify the purpose of each in 25 words or less. struct thread: - struct hash page_table ...page table of thread + struct hash page_table ...supplemental page table of thread struct page_table_entry: void *upage ...virtual address of page @@ -44,13 +44,28 @@ struct page_table_entry: >> determine the file and file offset corresponding to a virtual >> address? -TODO +When we try to insert a new segment into our supplemental page table we record some information in the struct segment of each page table entry. This struct contains + +-) the virtual address of the page +-) the type of the page table entry, weather it is an ordinary segment or a +memory mapped file page +-) if the page is already loaded or not (per default false) +-) the file the page corresponds to +-) the offset in the file +-) if the page is writable or not + +Lazy loading of pages is accomplished by not loading the page instantly. The +actual page-loading is done when a page-fault occurs. + ---- SYNCHRONIZATION ---- >> A3: How do you deal with or prevent page faults in file system >> routines. Argue why your solution is deadlock free. -TODO +As we do not have any global structures, that means they are per process and +per thread, page faults can not happen, the same argument goes for the +question of being deadlock free. File-structures are per process too, so only +one process can deal with a file at once. STACK GROWTH ============ @@ -68,14 +83,21 @@ extern void *syscall_sp ...stored stack pointer for the "page fault inside >> B2: Describe how you integrated the (potentially growing) stack segment >> into your page table management implementation. -TODO +The Stack growth itself is implemented in the page fault handler. The page +table is just needed to allocate a new page for the stack when it needs to +grow. ---- ALGORITHMS ---- >> B3: Explain how you detect a page fault which should trigger a ->> stack growth. What asssumptions are needed for your implementation +>> stack growth. What assumptions are needed for your implementation >> to work? -TODO +If we do not find a valid entry in our supplemental page-table it could be +very well be a valid stack access. The maximum offset we consider as a valid +access is due to the PUSHA instruction, which can try to access an address 32 +bytes below the current stack pointer. If this is the case we try to grow the +stack by one page. + MEMORY MAPPED FILES =================== -- cgit v1.2.3