On Fri, 12 Oct 2001, Joseph A Knapka wrote: > Sourav Sen wrote: > > > > On Fri, 12 Oct 2001, Joseph A Knapka wrote: > > > > > 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 > > > > Hi Joe, > > If the threading is not done using clone(), and is done in user > > level library, then what will be the case? Because then also A and B will > > share memory and I think CLONE_VM is not set, and we have COW pages after > > fork(). > > Well, if the threading is done by a user-mode library, the > kernel never comes into the question. That kind of threading > is done by the process manipulating its own stack and CPU > context without the kernel's knowledge; there is only one > process and one thread as far as the kernel is concerned. Agreed, but one of those threads can still call fork() and create a child process, and then perhaps the situation mentioned by Martin occurs, then how things are tackled? Note, now (A+B) and C do have COW pages. regards sourav - 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/
