Re: mapping pages into new address spaces

On 9/10/06, Joshua Haberman <[email protected]> wrote:
>
> Hmm, when you put it that way, I realize that my arguments probably aren't
> very compelling.  :)  But I'll say them anyway:
> 1. it makes more sense to me that if a pager knows it wants to do a
> mapping, it can just do it, instead of having to wait for a page fault.
> This is an argument of "it will make the API and potentially some programs
> easier to understand."
>

I don't think this has something todo with the API, it's just the thread
startup protocol.

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.
>

Performance arguments are always good arguments, so no worries.
Let's look at the situation:
We have a newly created, almost empty address space from 0-3G (not counting
KIP and UTCB area)
=> Every access in the AS will cause a TLB miss
=> Data is very likely not to be in the processor's caches
For me that means that the main costs of creating a new thread within a new
AS are TLB and cache misses, not the initial pagefault.
Furthermore i would argue to the contrary of what you said in 1., for me
sending an IPC containing an IP and an SP seems to be very inituitiv.
Another point is that if you look at the pagefault protocol you see that it
contains a fault address and the faulting ip. What values would you want the
kernel to fill in there? To savely execute a thread one has to set the SP of
the thread in addition to replying to the pagefault msg, since a reply to a
PF message only contains a map item. So that would be another call to
ExchangeRegisters which is very costy (and btw another way of starting a
thread if you want to set other general purpose registers too). So basicely
your suggestions overloads the purpose of the pagefault protocol and will
not gain any performance (because of the costy ExchangeRegisters).

-Bernhard