Question

Say a process is forked from another process. In other words, we replicate a process through the fork function call. Now since forking is a copy-on-write mechanism, what happens is that whenever the forked process or the original process write to a page, they get a new physical page to write. So what I’ve understood, things go like this when both forked and original processes are executing.

–> when forking, all pages of original and forked process are given read only access, so that the kernel get to know which page is written. When that happens, the kernel maps a new physical page to the writing process, writes the previous content to it, and then gives the write access to that page. Now what I am not clear about is if both fork and original process write to the same page, will one of them will still hold the original physical page (prior to forking that is) or both will get new physical pages. Secondly, is my assumption correct that all pages in forked and original process are given read only access at time of forking?

–> Now since each page fault will trigger an interrupt, that means each write to original or forked process will slow down execution. Say if we know about the application, and we know that alot of contiguous memory pages will be written, wouldn’t it be better to give write permission to multiple pages ( a group of pages lets say ) when one of the page in the group is written to. That would reduce the number of interrupts due to page fault handling. Isn’t it? Sure, we may sometimes make a copy unnecessarily in this case, but I think an interrupt has much more overhead than writing 512 variables of type long (4096 bytes of a page). Is my understanding correct or am I missing something?

Answer 1

If I’m not mistaken, one of the processes will be seen as writing to the page first. Even if you hae multiple cores, I believe the page fault will be handled serially. In that case, the first one to be caught will de-couple the pages of the two processes, so by the time the second writes to it, there won’t be a fault, because it’ll now have a writable page of its own.

I believe when that’s done, the existing page is kept by one process (and set back to read/write), and one new copy is made for the other process.

I think your third point revolves around one simple point: “Say if we know about the application…”. That’s the problem right there: the OS does not know about the application. Essentially the only thing it “knows” will be indirect, through observation by the kernel coders. They will undoubtedly observe that fork is normally followed by exec, so that’s the case for which they will undoubtedly optimize. Yes, that’s not always the case, and you’re obviously concerned about the other cases — all I’m saying here is that they’re sufficiently unusual that I’d guess little effort is expended on them.

I’m not quite sure I follow the logic or math about 512 longs in a 4096 byte page — the first time a page is written, it gets duplicated and decoupled between the processes. From that point onward, further writes to either process’ copy of that page will not cause any further page faults (at least related to the copy on write — of course if a process sites idle a long time that data might be paged out to the page file, or something on that order, but it’s irrelevant here).