Hi, On Wed, Mar 19, 2008 at 09:58:57AM -0400, Thomas Bushnell BSG wrote: > On Tue, 2008-03-18 at 10:14 +0100, [EMAIL PROTECTED] 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-
