Hello Joe, Thanks again for your answer. I have one more question regarding a statement you make in your answer: Joseph A Knapka wrote: > > In this case, A and B will always share page mappings, even > when writing to copy-on-write pages, and C will get its own > copy if/when it attempts to write the page. Here's why: > > In do_fork(), we call copy_mm(), which, in the case of > CLONE_VM being set, just copies the entire mm context > for the new thread, -without- marking anything copy-on-write. > So thread A and thread B both have non-COW mappings. > > When Thread B forks process C, C gets an entirely new MM > context, with -no- user-space PTEs. So in order to write > A+B's virtual page, C takes a "not-present" page fault.regards Why is it that C will have no user-space PTEs in it's MM. I thought at a fork call, the user-space PTEs are copied from the parent's MM into the childs MM, and write protected in both MMs. I concluded that from the following call sequence (in 2.4.10): do_fork() -> copy_mm() --> dup_mmap() [note that since C is created by a call to fork(), CLONE_VM is *not* set, when creating C] ---> copy_page_range() [here the PTEs are copied for one vmarea; both PTEs (child and parent) are write protected at line 256, if the conditions to make them COW are fullfilled]. My understanding was therefore that all physical pages backing A&B's page mapping would now be shared among A&B and C, and write access to this pages (by either A/B or C would cause a copy-on-write). Did I misunderstand somthing in your answer or in the source code? regards Martin -- Supercomputing System AG email: maletinsky@scs.ch Martin Maletinsky phone: +41 (0)1 445 16 05 Technoparkstrasse 1 fax: +41 (0)1 445 16 10 CH-8005 Zurich - Kernelnewbies: Help each other learn about the Linux kernel. Archive: http://mail.nl.linux.org/kernelnewbies/ IRC Channel: irc.openprojects.net / #kernelnewbies Web Page: http://www.kernelnewbies.org/
