From f442c3fbe203752f0a751317d3e833fe0b660ae1 Mon Sep 17 00:00:00 2001 From: manuel Date: Thu, 21 Jun 2012 19:07:57 +0200 Subject: use void* instead of uint8_t* in mmap/page table and fill in more of proj2 --- proj2.txt | 44 ++++++++++++++++++++------------------------ 1 file changed, 20 insertions(+), 24 deletions(-) (limited to 'proj2.txt') diff --git a/proj2.txt b/proj2.txt index 3b89826..8dd36f2 100644 --- a/proj2.txt +++ b/proj2.txt @@ -30,13 +30,12 @@ Manuel Mausz >> enumeration. Identify the purpose of each in 25 words or less. struct thread: - struct hash page_table ...supplemental page table of thread + struct hash page_table ...supplemental page table of thread struct page_table_entry: void *upage ...virtual address of page bool loaded ...indicates if page is loaded - enum type ...type of page - union struct segment ...structure needed for lazy loading of data segments + struct segment ...structure needed for lazy loading of data segments struct hash_elem elem ...Hash element. ---- IMPLEMENTATION ---- @@ -44,28 +43,25 @@ struct page_table_entry: >> determine the file and file offset corresponding to a virtual >> address? -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 +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 +* if the page is already loaded or not +* the associated file +* 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. 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. +per thread, page faults can not happen. The same argument goes for the +question of being deadlock free. STACK GROWTH ============ @@ -83,9 +79,10 @@ 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. -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. +The stack growth itself gets triggered by the page fault handler just as the +lazy loading of pages. Other than that there's no association between the pages +of the stack and the pages of segments/mmapped files. +So pages of the stack don't get tracked inside the page table at all! ---- ALGORITHMS ---- >> B3: Explain how you detect a page fault which should trigger a @@ -93,11 +90,10 @@ grow. >> to work? 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. - +very well be a valid stack access. The maximum offset we consider a valid +access is caused by the PUSHA instruction, which may try to access an address +32 bytes below the current stack pointer. Everthing higher we consider +an exception. MEMORY MAPPED FILES =================== -- cgit v1.2.3