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
next prev parent 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