Re: K42 OS

[Michal Ostrowski <mostrows@xxxxxxxxxxxxxx>]

> Also, you folks have an interesting method of reporting kernel/upcall events,
> round robbin queue with exception vectors, if my memory serves me correctly,
> which seems much less hack than the mailbox stuff in FreeBSD-current. Also, you

We have a messaging facility we generically call "PPC" -- Protected
Procedure Call.  The idea here is that "messages" between processes
(which may include the kernel) are implemented using procedure call
semantics and interfaces.   In the synchronous version of a PPC call
arguments are marshalled into a transfer page, and control is
transferred to the targeted process that implements the call.  While the
call is being performed the caller application is still runnable (other
threads may run), the calling thread is in a state that marks it as
waiting for a reply.  When the call is complete and the results
transferred back to the caller the calling thread is resumed.  

In the asynchronous version of a PPC, the arguments to the PPC call are
collected in a special buffer of the receiving process that accumulates
all incoming asynchronous calls, and a "soft interrupt" bit is raised. 
When a soft interrupt is raised, the kernel makes the process runnable
if it was not already and enters the process at a special entry point. 
The process then proceeds ton instantiate threads to service the async
requests.

In the interest of brevity I'm doing a real hack of an explanation
here.  There is something underlying all of this that I really need to
stress;  the K42 implementation of all this stuff makes this all work by
having tight integration between the threading, scheduling and messaging
facilities.   For example, our core threading facilities must be able to
recognize that threads are not runnable since they are waiting for a
message response.  Also, when we make a synchronous call, the time spent
servicing that call should count towards the run-time of the caller
process, even though another process is actually executing. (I could go
on and on, there are many corner cases to worry about.)


> folks have another really interesting thing with the option of doing both soft
> and hard preemption for the userspace threading system, where the "soft" method
> is a request to the thread-kern to save its state in userspace if possible within
> a certain time frame, while the "hard" version has the kernel do a full context
> save explicitly. The previous method is presumed to be faster.
> 

Correct.


> Last paper I read, you folks where having a problem with process migration with
> your scheduler activations stuff. Not sure what can be said here. Did you guys fix
> it or find the problem ? ;)
> 

That is being worked on.  I am assuming that you are referring to the
issue of how to determine which processor a process should be bound to.

> Just trying to fuel a conversation here. :)
> 
> I think you'll find Matt and a number of his cohorts to be an open minded people
> and willing to learn from other folks, which is why me and other people have faith
> in his ideals since he's focus on the relevant SMP scalability issues.

That's reassuring to hear.  I certainly hope we can foster a lively
discussion.


-- 
Michal Ostrowski <mostrows@xxxxxxxxxxxxxx>

Attachment: signature.asc
Description: This is a digitally signed message part