0

Operating System Concepts say

fork() we can use a technique known as copy-on-write, which works by allowing the parent and child processes initially to share the same pages. ... When it is determined that a page is going to be duplicated using copy- on-write, it is important to note the location from which the free page will be allocated. Many operating systems provide a pool of free pages for such requests. These free pages are typically allocated when the stack or heap for a process must expand or when there are copy-on-write pages to be managed. Operating systems typically allocate these pages using a technique known as zero-fill-on-demand. Zero-fill-on-demand pages have been zeroed-out before being allocated, thus erasing the previous contents.

Is copy-on-write not implemented based on page fault? (I guess no)

Do copy-on-write and page fault share the same pool of free pages? If not, why? (I guess no)

Is malloc() implemented based on page fault? (I guess yes, but not sure why it shares the same free page pool as copy-on-write, if that pool is not used by page fault)

Thanks.

Improve this question

2 Answers 2

Reset to default
4

(Since this is tagged , I’m answering in that context. None of this is exclusive to Linux.)

Is copy-on-write not implemented based on page fault?

It is based on page faults. “Copied” pages are marked read-only. When a process tries to write to them, the CPU faults and the kernel duplicates the page before restarting the write.

Do copy-on-write and page fault share the same pool of free pages? If not, why?

Yes, they do.

Is malloc() implemented based on page fault?

malloc() itself doesn’t manipulate the address space or allocated pages; it’s handled entirely by the C library. The function used to allocate memory to the heap is brk(), and yes, it relies on page faults: allocated pages are marked not-present. This relies on a “present” bit in the corresponding page table entry, which the kernel and MMU use to track whether the page is accessible in memory. Any access to a non-present page causes a fault, and the kernel allocates a page and restarts the faulting instruction.

Improve this answer
9
  • Thanks. "“copied” pages are marked read-only. When a process tries to write to them, the CPU faults". Are the CPU faults page fault exception? Are they handled by the page fault service routine? Commented Oct 15, 2018 at 17:44
  • Thanks. When calling malloc(), how is the page table updated to the virtual address returned by the function? The virtual address can't be mapped to a physical memory address. Is the virtual address mapped to "null" or some other value, so that page fault can happen when access that virtual address? Commented Oct 15, 2018 at 22:04
  • In the case of vfork(), is the "copy on exec()" (as opposed to "copy on write") also based on page fault? (I guess no, exec() does the copy by itself without need of page fault handling.) Commented Oct 16, 2018 at 1:03
  • See my updated. Regarding “copy on exec()”, I’m not sure what you mean; could you clarify your question? Commented Oct 16, 2018 at 7:30
  • Here is what I meant by "copy on exec()": A process vfork() a child, then the child exec(), and exec() will allocate new space for the child. Is it correct that "copy on exec()" is not based on page fault, because exec() does the "copy" by itself without need of page fault handling? Commented Oct 16, 2018 at 17:41
2

Copy on Write is implemented based on implicit interrupt generated by MMU (Memory Management Unit). Example reasons for page fault are as follows.

A page fault is also an implicit interrupt generated by MMU but both are NOT same. Some reasons for a page fault are following.

Invalid Memory access: A page fault occurs when a page desired by a user process is not present in memory. Page fault may occur if a process wants to access a virtual address that is not allocated to it (commonly known as segmentation fault). Or it may occur if a page is swapped out.

Copy on Write: One reason for a page fault is Copy On write. During a fork() system call OS allocate same memory for both child and parent and marks the memory as read-only. This saves huge copy penalty. Assume the child calls an exec just after fork. If copy on write was not employed the entire copied page would be flushed during exec. When either parent or child try to write on that page it creates a page fault. Then OS allocate a new page and remove read-only restrictions.

Copy on Demand: Another reason for a page fault is copy on demand. When a user process asks for a new page in its virtual address range OS may allocate a virtual address without allocating a physical address corresponding to it. When the process tries to access that page it generates a page fault. OS then allocate a physical page corresponding to the virtual page.

So, a page fault may NOT need a fresh page to be allocated (in the case when it's generated from an error). But if a page fault needs a fresh page the page comes from the same pool of pages from where a page comes to server copy on write.

malloc implementation is not related with copy on write.

NOTE An Operating System can work without Copy on Write and Copy on Demand. Although it'll not perform well. But page fault mechanism is necesseary for an OS to support `paging'

Improve this answer

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.