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