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.

I'm sorry, I must not have been clear about what I am proposing.  I am not
talking about the thread startup protocol per se.  I am talking in general
about what happens to MapItem IPCs that a pager sends to any of its
threads.

When a pager receives a page fault IPC, it sends a MapItem/GrantItem IPC
in reply.  The kernel automatically accepts this MapItem/GrantItem by
setting the acceptor to the entire address space, and furthermore the
thread that faulted never actually receives this MapItem/GrantItem.

However, when a pager sends exactly the same MapItem/GrantItem IPC but
*not* in response to a page fault, the thread has to explicitly receive
this IPC and the IPC is subject to its acceptor.

What I am proposing is to make the second case more like the first.  Make
all MapItem/GrantItem IPCs that come from a thread's pager behave like
IPCs sent in response to page faults, namely:

1. they are not subject to a thread's acceptor
2. they automatically take effect without being explicitly received

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

Thanks for this analysis.  I can see that for initial thread creation page
faults are probably not the main expense.  What about later in a thread's
life though?  Suppose that a thread requests more memory from its pager. 
With the current API, that would look like:

thread -> pager IPC (please give me some memory)
pager updates page tables
pager -> thread IPC (request successful)
thread attempts to access new memory
thread -> pager IPC (page fault)
pager looks in page tables
pager -> thread IPC (grant/map)

If my proposal were supported, this could become:

thread -> pager IPC (please give me some memory)
pager updates page tables
pager -> thread half-IPC (map/grant that is automatically accepted by the
kernel)
pager -> thread IPC (request successful)

This would save both an extra page table lookup and the page fault.  Now
you might say "why not just do this:"

thread sets acceptor to entire address space
thread -> pager IPC (please give me some memory)
pager updates page tables
pager -> thread IPC (request successful + fpage)
thread sets acceptor back to what it will accept from other threads

The one downside of this is that it counts on the thread to set its
acceptor properly, or the pager's fpage will go to the wrong place.  It
seems like a pager should have complete control over its threads' address
spaces, and be able to map things wherever it wants, whenever it wants to.

Does this make sense?

Thanks,
Josh