1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
|
+---------------------------+
| ProgOS |
| PROJECT 2: VIRTUAL MEMORY |
| DESIGN DOCUMENT |
+---------------------------+
---- GROUP ----
>> Fill in the names and email addresses of your group members.
Peter Ketscher <e9651415@mail.student.tuwien.ac.at>
Karoline Knoth <e0326266@student.tuwien.ac.at>
Manuel Mausz <manuel-uni@mausz.at>
---- PRELIMINARIES ----
>> If you have any preliminary comments on your submission, notes for the
>> TAs, or extra credit, please give them here.
>> Please cite any offline or online sources you consulted while
>> preparing your submission, other than the Pintos documentation, course
>> text, lecture notes, and course staff.
PAGE TABLE MANAGEMENT
=====================
---- DATA STRUCTURES ----
>> A1: Copy here the declaration of each new or changed `struct' or
>> `struct' member, global or static variable, `typedef', or
>> enumeration. Identify the purpose of each in 25 words or less.
struct 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 hash_elem elem ...Hash element.
---- IMPLEMENTATION ----
>> A2: Describe how you implemented lazy page loading. How do you
>> 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
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.
STACK GROWTH
============
---- DATA STRUCTURES ----
>> B1: Copy here the declaration of each new or changed `struct' or
>> `struct' member, global or static variable, `typedef', or
>> enumeration. Identify the purpose of each in 25 words or less.
extern void *syscall_sp ...stored stack pointer for the "page fault inside
syscall/kernel"-case
---- IMPLEMENTATION ----
>> 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.
---- ALGORITHMS ----
>> B3: Explain how you detect a page fault which should trigger a
>> stack growth. What assumptions are needed for your implementation
>> 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.
MEMORY MAPPED FILES
===================
---- DATA STRUCTURES ----
>> C1: Copy here the declaration of each new or changed `struct' or
>> `struct' member, global or static variable, `typedef', or
>> enumeration. Identify the purpose of each in 25 words or less.
struct page_table_entry:
union struct TODO ...structure needed for loading of memory mapped files
---- ALGORITHMS ----
>> C2: Describe how memory mapped files integrate into your virtual
>> memory subsystem.
TODO
>> C3: Explain how you determine whether a new file mapping overlaps
>> any existing segment.
TODO
---- RATIONALE ----
>> C4: Mappings created with "mmap" have similar semantics to those of
>> data demand-paged from executables, except that "mmap" mappings are
>> written back to their original files, not to swap. This implies
>> that much of their implementation can be shared. Explain why your
>> implementation either does or does not share much of the code for
>> the two situations.
TODO
SURVEY QUESTIONS
================
Answering these questions is optional, but it will help us improve the
course in future quarters. Feel free to tell us anything you
want--these questions are just to spur your thoughts. You may also
choose to respond anonymously in the course evaluations at the end of
the quarter.
>> In your opinion, was this assignment, or any one of the three problems
>> in it, too easy or too hard? Did it take too long or too little time?
>> Did you find that working on a particular part of the assignment gave
>> you greater insight into some aspect of OS design?
>> Is there some particular fact or hint we should give students in
>> future quarters to help them solve the problems? Conversely, did you
>> find any of our guidance to be misleading?
>> Do you have any suggestions for the TAs to more effectively assist
>> students, either for future quarters or the remaining projects?
>> Any other comments?
|
