Martin Maletinsky wrote: > > Hello Joseph, > > Thank you for your quick answer. I am afraid I was not sufficiently clear about the details in my scenario. So let me re-phrase the situation: > > A and B are threads (i.e. they share their VM). Thread A initiates a disk-read and sleeps. Thread B calls fork(), creating a process C. I didn't mention process C in my previous > mail, since it is not relevant to the susequent scenario. With respect to this scenario the only relevant effect of B's call to fork() is that all pages within B's address space > are now marked copy-on-write (and the same holds for the pages within A's address space, since A and B share their address spaces). > > > > (2) How is I/O synchronized with the copy-on-write mechanism? Imagine the following scenario: > > > > > > (i) Two threads A and B share their virtual address space (i.e. the CLONE_VM flag was set when A called clone() to create B). Oops, I missed the VM_CLONE... > > > > > > (ii) Thread A starts reading data from a hard disk into a buffer BUF which lies within virtual page VP_1 (which at that moment corresponds to the physical page PP_1). In > > > order to service the read request, the physical page PP_1 is locked (?) and DMA is set up, to transfer data from the harddisk into the correct location within physical page > > > PP_1. > > > > > > (iii) Thread A sleeps until termination of it's read request. > > > > You really mean "process" here, because threads share VM (so > > no copy-on-write, etc.) > > No, A and B are threads and they *do* share their VM, by assumption. copy-on-write results from B's call to fork() and will result in separating A and B's address space from the > address space of the newly created process C. 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. do_no_page() then makes a new copy of the page for C, because C's vm_area is not shareable (line 1245 of memory.c in 2.4.10). If C first reads the page, it shares the page with A+B, but C's PTE is write-procected (line 1276), and thus it will get its own copy in do_wp_page() if it tries to write the page later. Cheers, -- Joe # "You know how many remote castles there are along the # gorges? You can't MOVE for remote castles!" - Lu Tze re. Uberwald # Linux MM docs: http://home.earthlink.net/~jknapka/linux-mm/vmoutline.html - 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/
