On Thu, Aug 07, 2003, Ed L Cashin wrote:
> "Luoqi Chen" <[EMAIL PROTECTED]> writes:
>
> [Ed writes]
> >> That means that if I do this:
> >>
> >> for (i = 0; i < n; ++i) {
> >> assert(!mprotect(p, pgsiz, PROT_NONE));
> >> assert(!mprotect(p, pgsiz, PROT_READ|PROT_WRITE|PROT_EXEC));
> >> p[i] = i & 0xff;
> >> }
> >>
> >> ... I get n minor page faults! Pretty amazing, but I guess they
> >> figured nobody does that.
>
> ...
> > The first mprotect() removes the physical mapping from the page
> > table, the second mprotect() doesn't do anything because the mapping
> > isn't there. So when the page is accessed, a fault is needed to
> > insert the mapping back to the page table.
>
> OK, thanks. I can see that in sys/i386/i386/pmap.c. It leaves me
> wondering what MAP_ENTRY_COW is for, though.
It's an optimization that makes the map entries and corresponding
vm_objects themselves copy-on-write. Specifically, when a process
forks, FreeBSD does not allocate new shadow objects immediately.
This is deferred until the object needs to be modified, which is
usually never if the process subsequently calls exec.
_______________________________________________
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
