DragonFly kernel List (threaded) for 2003-11
Re: K42 OS
: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
: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
:(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.)
: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.