Ok. I'm wondering if it's not just a side effect that only _looks_
odd. It is expected that the balancing code unmaps the page from the
process. Possibly gnumach doesn't bother with remapping it, because it
does not really *have* to, it can as well just defer that until the page
is really needed again. And thus the RSS of the process stays lower in
the meanwhile. Reading the pages again from userland would make gnumach
have to remap them. Normally it will be able to find them in the memory
object.
*) The page data is then copied from old to new. There is a call to
pmap_clear_modify for the new page if the old page wasn't 'dirty'
Yes, because have have just written to the new page, so of course the
hardware dirty flag is set, but we don't want to infer from that that
the page is dirty if it wasn't already, so we clear the hardware flag.
but what about the case where the old page was dirty?
In that case the memcpy(&dest->vm_page_header, &src->vm_page_header)
will have copied the dirtiness information. The hardware page flag will
also have a modified bit from the memcpy, but that's fine since the page
was already marked dirty.