[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Thread model

From: olafBuddenhagen
Subject: Re: Thread model
Date: Wed, 19 Mar 2008 21:48:17 +0100
User-agent: Mutt/1.5.17+20080114 (2008-01-14)


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,

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]