The holy bible of SWEB - Institute of Applied Information Processing ...

3.7. EXTENDING SWEB CHAPTER 3. VM, PROTECTION AND PAGING
Figure 3.4: Page-Fault-Handling with possible CopyOnWrite
3.7.5 CopyOnWrite
A more efficient way, would be not to copy all pages, but, on demand, only copy pages
that get modified. Such a mechanism is called CopyOnWrite. We might implement
CopyOnWrite in Sweb by first marking all user pages as read-only. When creating a
new process, instead of copying the kernel page directory, we copy the one from the
original user process. This way, we can save memory space as well as the time it takes
to create a new user process.
Because both user process pages are read-only, writing on them will cause a page
fault. Flag WP in CR0 should be set, so this happens even on a write performed by
kernel code. To copy pages on demand the page fault handler needs to be modified to
recognise a shared page and copy that page to a new location where it can be written
to. An example of how the page fault handler might work can be found in Figure 3.4.
Obvious care is necessary in administrating shared physical pages, i.e. a shared
page can only be freed if all user processes using it have terminated. A possible
solution might be to manage a reference counter for each physical page, however in
combination with virtual memory this is not enough.
48 of 151