The child gets a copy of the list of mappings (start, end, flags), but
does not touch, or walk, the tree which manages the individual pages.
Permission/access checking was already done by the parent process.
1Gib mapped is no different from 10000000Gib mapped, in this case.
Remember, the VM system is independent from the individual process,
and the process/page/tlb relationship is established, in multiple
stages, at the time of the first access. This applies to a process,
and the same applies to a fork()ed child of a process too.
Page retirement is done globally too. There is a daemon, which
periodically wakes up, or wakes up if memory pressure occurs, and
unmaps pages to free memory. munmap() just removes the entry from the
list of mappings (start, end, flags), and ensures that all data for a
file mapping have been written to the file page cache, before
returning, but the actual removal of page entries is left to the
global daemon. Some Unix implementations do the same, if a process
terminates, to prevent that the daemon gets too much work, but in
normal circumstances the page removal is done asynchronously .
Olga
On Fri, Sep 13, 2013 at 11:59 PM, Glenn Fowler <g...@research.att.com> wrote:
>
> we're getting close
> again we're not interested in the pages
> but the metadata for the pages
>
> this may be based on incorrect assumptions ...
> 1Gib mapped and 8Kib page size => 131072 entries for address-to-page lookup
> at fork() time the parent process has that 131072 entry table in hand
> what does the child get? a copy of that 131072 entry table or a reference?
>
> On Fri, 13 Sep 2013 23:26:34 +0200 =?KOI8-R?B?z8zYx8Egy9LZ1sHOz9fTy8HR?=
> wrote:
>> 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 <g...@research.att.com> 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`\/ }
>> .----'-/`-/ olga.kryzhanov...@gmail.com \-`\-'----.
>> `'-..-| / http://twitter.com/fleyta \ |-..-'`
>> /\/\ Solaris/BSD//C/C++ programmer /\/\
>> `--` `--`
>
--
, _ _ ,
{ \/`o;====- Olga Kryzhanovska -====;o`\/ }
.----'-/`-/ olga.kryzhanov...@gmail.com \-`\-'----.
`'-..-| / http://twitter.com/fleyta \ |-..-'`
/\/\ Solaris/BSD//C/C++ programmer /\/\
`--` `--`
_______________________________________________
ast-users mailing list
ast-users@lists.research.att.com
http://lists.research.att.com/mailman/listinfo/ast-users
