Re: K42 OS

[Bill Huey (hui) <billh@xxxxxxxxxxxxxxxxx>]

On Sat, Nov 22, 2003 at 05:31:53PM -0800, Matthew Dillon wrote:
> :
> :In sending async messages, how does one handle situations where the
> :receive buffer of the target is full?
> :
> :When doing a synchronous message, what happens is the receiver at the
> :moment is not willing to receive? (we want to efficiently be able to
> :retry later by some means)
> 
>     There is no 'buffer'.  The message itself is the buffer.  If
>     the client allocated the message then we are simply talking
>     about linking and unlinking it from various queues.
> 
>     For system calls its a little more complicated because for
>     security reasons the kernel has to copy the message into
>     kernel space.  In this case the kernel will have to impose
>     a limit on the number of outstanding messages it will allow
>     a process to queue.  When the limit is reached the 
>     assumption is that something has gone wrong and the kernel
>     will have to block the caller until the queue drops down
>     a bit.

I was talking about K42's problems with messaging, not dfBSD's, if that
wasn't clear.

> :An IPC is handled on a thread that is running in the "server" process.
> :How is that thread scheduled (what priority)?  How do we account for the
> :time? (In K42 we attempt to charge time a process spends servicing IPC
> :requests to the callers of those services.) =20
> : =20
> :(This is not my particular area of expertise, I'm just referring to some
> :issues off the top of my head.  I can certainly refer you to someone who
> :is our real expert in this area with specific questions.)
> :--=20
> :Michal Ostrowski <mostrows@xxxxxxxxxxxxxx>
> 
>     It depends on what the thread is.  If we are talking about a 
>     kernel-only thread then there is a strict fixed priority.  e.g.
>     interrupts have the highest priority, then software interrupts
>     (like protocol stacks), then mainstream kernel threads, then
>     kernel threads acting on behalf of a user proccess, then threads
>     running user processes.
> 
>     If the thread is a user process then the standard userland 
>     dynamic priority management mechanism is used within the userland
>     thread grouping.  Userland processes can be on one of three queues:
>     The idle queue, the normal dynamic priority queue, or the realtime
>     queue (which in BSD parlance is not hard realtime but soft realtime...
>     user processes competing with other user processes, not user processes
>     competing against kernel threads).
> 
>     In DragonFly process time is charged statistically.  A clock 
>     interrupt (about 100Hz normally) comes along and checks 
>     to see what it interrupted... something that was running in
>     usermode, in kernel mode, etc... and increments the appropriate
>     counter.  We do not attempt to keep track of exactly how
>     much time particular aspects of an operation take because
>     the information is not really useful (that is, over time it
>     is no more accurate then what the statistical model produces),
>     plus putting timekeeping functions in the critical path is,
>     well, a waste of cpu cycles.

I was talking about their implementation of their userspace threading
system, not dfBSD's. Not sure if I'm too offtopic, but I thought it
would be interesting to see what their insight is for their
implementation.

bill