Re: mapping pages into new address spaces

 > 2. I don't know the cost of handling page faults, but if they are at
> all expensive, proactively mapping pages will help avoid them.  This
> is an argument of performance.

If I understand you right you want to map all or at least most of the
pages a task needs before it actually starts, i.e. not on demand, to avoid
the costs of pagefault handling at runtime.
I don't know whether these costs a high (as Bernhard said, you have TLB-
and cache-misses anyway), but I think there are also ways to map the
entire binary or at least large parts of it into the address space before
the thread starts if you really want/need to do so.
As far as I understand the pagefault protocol, the pager is only expected
to reply with a single fpage, and no other restrictions are made on how
this fpage must look like.
So it should be possible (but I'm not sure about that) for the pager to
reply with a fpage larger than the hardware pagesize, thus mapping a
contigous region of virtual memory, for example a larger part of the
task's binary.
There's another approach I once heard: The pager could also reply with the
"wrong" page, i.e. a page at another address than the one the thread
faulted on. This would lead to another page fault when the threads
resumes. The pager could postpone the demanded page until the entire
address space is mapped. This approach of course doesn't reduce the number
of pagefault IPCs (it might even increase it, because it might map pages
that are not needed), but you could set up the address space before the
thread starts to execute.
And a final idea: I think you could also map some "startup code" upon the
first page fault, which could accept further mappings, set up the initial
stack etc. and finally call the "real" thread.

-Philipp