Hi again, I got the concept. I had no problem understanding the explanation...I already knew the concepts of virtual memory and paging so that was not a problem.
According to ur reply, after the sharing, will always the range of addresses generated by the process, ie the virtual addresses be the same of the parent, even if the physical memory pointed to by that is different. So basically, is it that sharing VM imply that the range of addresses is shared, and physical pages pointed to by them may or maynot be the same? Please do help, and thanks for the previous elaborate explanation! On Sat, 2004-11-20 at 19:29, Simon Valiquette wrote: > Jagadeesh Bhaskar P a écrit : > > Hi, > > > > When a process forks, every resource of the parent, including the > > virtual memory is copied to the child process. The copying of VM uses > > copy-on-write(COW). I know that COW comes when a write request comes, > > and then the copy is made. Now my query follows: > > > > How will the copy be distributed. > > If a child modify a page that is shared with his parent, this page > will be copied to a new page. Then his page table will be modified to > point to this new page and reloaded in the MMU. Only then the running > process will normally modify his own copy of that page. > > It works the same way if it is the parent that modify the page. > Otherwise we would have a problem if the parent have many childs. It > also simplify things a lot for SMP systems. > > > Be carefull: "page" and "page table" are 2 very different things. > > "Page table" will point to a page struct > "page" is a struct that point to a physical page, or to a swap area > (if I remember well). > Virtual memory is the address seen by the program. Two identical > virtual adresses will normally point to different physical locations. > > > Note that each process have his own copy of his memory page table > since the fork. And the page table will typically point to many memory > pages. > > The shared pages pointed by the 2 page tables are only thoses where > the data are still unmodified since the fork. > > > > Whether giving the child process a new > > copy of VM be permanent or whether they will be merged anywhere? > > Its permanent at the page level. Anyway, once modified, it is very > unlikely that the page will ever be identical again. > > Also, they never really shared the same virtual memory space since > they each have their own page tables. Their pointers use the same > virtual addresses, but they are resolved to the same physical pages only > for the pages that are still identicals. > > > I'm not sure if you understand properly how the virtual memory is > working at the processor level, but it is very important if you want to > understand how COW is working. > > > And > > shouldn't the operations/updations by one process be visible to the > > other which inherited the copy of the same VM? > > > > No, it must be completelly transparent for the process and they > should not be able to see the modifications (otherwise we have a > security bug). > > You must know that the processor use the MMU to resolve the memory > page physical address. Since each process have his own memory table, a > pointer to an identical virtual adress usually point to a different > physical address. So it means that once a shared page is copied and > unlinked by modifying the page table of one of the process, the same > pointer with the same pointing adress will now point to 2 different > physical memory location. All of that magic is done thanks to the MMU. > > > I don't know if the kernel is doing COW at all in the case of a > MMU-less processor (usually a microcontroler). > > > How can this work? Can someone please help me on this regard? > > > > I think I gave a good overview of the question. I tried to keep > things as simple as I could, at the cost of not giving an exact > description of how Linux handle COW. For example, there is in fact 3 > levels of page table indirections in Linux, but it was not necessary to > understand COW. > > > Simon Valiquette > > --- > Often, the source contains important documentation > - Slackware FAQ, 1993 > > > - > To unsubscribe from this list: send the line "unsubscribe linux-newbie" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.linux-learn.org/faqs -- With regards, Jagadeesh Bhaskar P R&D Engineer HCL Infosystems Ltd Pondicherry INDIA - To unsubscribe from this list: send the line "unsubscribe linux-newbie" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.linux-learn.org/faqs
