Re: Thread model

[olafBuddenhagen]

Hi,

On Wed, Mar 19, 2008 at 09:58:57AM -0400, Thomas Bushnell BSG wrote:
> On Tue, 2008-03-18 at 10:14 +0100, olafBuddenhagen@gmx.net wrote:

> > I must admit that I do not fully understand the relation between
> > filesystems and paging yet... Probably this is what I really meant
> > to say :-)
> 
> Here's what you need to know.
> 
> The virtual memory in the process is associated with a "memory object"
> which is just a port to some server, normally a file server.  This
> association is set up by the vm_map call.  In response, the kernel
> sets up memory maps internally, and saves the memory object port
> provided for future use.
> 
> When a page fault occurs, the thread enters the kernel.  The kernel
> recognizes the page fault, looks in the memory maps to find the memory
> object in question, computes the right offsets, and then sends a
> request to the memory object for the page in question.  When the
> server responds with the data, the kernel installs the page in core,
> adjusts the memory maps, and returns from the page fault.

Thanks for the explanation!

> Now the basic idea behind using one kernel thread to handle several
> user threads is that when a user thread *would* block, you don't let
> it block, instead you just take it away and run some other user
> thread. That works very nicely in Mach, in general, because almost all
> blocks happen inside mach_msg, and mach_msg was carefully constructed
> to make this work nicely.
> 
> But there is a wrinkle: page faults.  When I say "almost all blocks
> happen inside mach_msg" that's because one important category does
> not: page faults.  Or rather, the page fault also blocks in a message
> send, but the message send is one that is done by the thread in kernel
> space, rather than by the user space mach_msg, and so the user-space
> threads library has no access to it.

I see.

And pagefault handling can be recursive, and thus just ignoring that
problem and letting the process block completely is not an option,
right?

> It is hard to see how to fix this without one of the following:
> 
> 1) Having the kernel know that user threads are multiplexing, and do
> some fancy callout stuff when page fault waits occur;

I don't know how tricky it is to implement this. But I think the real
problem here is that the tread doesn't know about the fault beforehand,
and thus can't store the important state bits explicitely. This totally
breaks the model I envisioned :-(

-antrik-