public inbox for linux-newbie@vger.kernel.org
 help / color / mirror / Atom feed
From: Simon Valiquette <v.simon@ieee.org>
To: linux-newbie@vger.kernel.org
Subject: Re: Query regarding Copy-on-write
Date: Sat, 20 Nov 2004 08:59:03 -0500	[thread overview]
Message-ID: <419F4DA7.1070606@ieee.org> (raw)
In-Reply-To: <1100947162.4038.43.camel@myLinux>

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 majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

  reply	other threads:[~2004-11-20 13:59 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-11-20 10:39 Query regarding Copy-on-write Jagadeesh Bhaskar P
2004-11-20 13:59 ` Simon Valiquette [this message]
2004-11-20 14:22   ` Jim Nelson
2004-11-22  3:34   ` Jagadeesh Bhaskar P
2004-11-22  6:31     ` Simon Valiquette
2004-11-22  6:49       ` Jagadeesh Bhaskar P
2004-11-22 11:48         ` Simon Valiquette
2004-11-23  4:00           ` Manish Regmi
2004-11-20 14:17 ` Jim Nelson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=419F4DA7.1070606@ieee.org \
    --to=v.simon@ieee.org \
    --cc=linux-newbie@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox