No, this is not copy on write, this is check-what-to-do-on-access-when-not-mapped. The short explanation is, that the fork() is not the time when an action in the VM system will happen, its the time of the first access to a page, which is not mapped yet, in the current process, when an action will happen. What is copied at fork() time, is the range information, i.e. mapping from/to/flags, but not the individual pages. So the number of mapped areas is a concern at fork() time, but not their size.
Olga On Fri, Sep 13, 2013 at 11:20 PM, Glenn Fowler <[email protected]> wrote: > > On Fri, 13 Sep 2013 23:14:22 +0200 =?KOI8-R?B?z8zYx8Egy9LZ1sHOz9fTy8HR?= > wrote: >> Glenn, shared mmap() mapping do not have any impact on fork() >> performance, at least on VM architectures who can share pages (this is >> common practice since at least SystemV, and no modern Unix or Linux >> exists which does not do copy-on-write, but more on that below) The >> pages are not even touched, or looked at at fork() time, so even >> millions of mmap() pages have no impact. >> Only if the pages are touched the VM system will realize a fork() has >> happened, and *may* create a copy-on-write copy if you write to it. If >> you only read the pages nothing will happen. > > thanks > > we weren't concerned about the pages themselves > but the TLB or whatever the vm system uses to keep track of pages > that has to be duped on fork(), no? > or are you saying even that is copy on write? > -- , _ _ , { \/`o;====- Olga Kryzhanovska -====;o`\/ } .----'-/`-/ [email protected] \-`\-'----. `'-..-| / http://twitter.com/fleyta \ |-..-'` /\/\ Solaris/BSD//C/C++ programmer /\/\ `--` `--` _______________________________________________ ast-users mailing list [email protected] http://lists.research.att.com/mailman/listinfo/ast-users
