Re: K42 OS

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

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

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

					-Matt
					Matthew Dillon 
					<dillon@xxxxxxxxxxxxx>