Re: K42 OS

[Michal Ostrowski <mostrows@xxxxxxxxxxxxxx>]

On Sat, 2003-11-22 at 20:31, Matthew Dillon wrote:
> :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.

Agreed... I like statistical approaches to this.  Does this timer drive
quantum expiration as well?


The K42 approach is that we choose some process to run and give it a
quantum.  During that time the process may run in its own space, or make
calls to other processes.  When other processes are running serving
calls, that time is counted against the original process (to whom the
current quantum was issued). 


K42 does not have a regular timer that goes off every x ms.  We have a
timer for quantum expiration but that may not mean that it goes off
regularly in a predictable manner.  The K42 kernel keeps track of only
one timer event per process (i.e. the next timer event to go off). 
Applications manage their own timer queues and submit only the "next"
timer to the kernel, allowing for efficient addition and removal (since
we don't expect that timers will expire without having been cancelled).

-- 
Michal Ostrowski <mostrows@xxxxxxxxxxxxxx>

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