[prev in list] [next in list] [prev in thread] [next in thread] 

List:       eros-arch
Subject:    A New Process State
From:       Bill Frantz frantz () netcom ! com
Date:       1995-09-11 23:38:37
[Download RAW message or body]

At 13:25 9/10/95 -0400, Jonathan Shapiro wrote:
>In the current KeyKOS design, a process that blocks in the kernel gets
>bounced all the way back to user mode, with it's PC pointed at the
>trap instruction that started the whole mess.  This has the following
>consequences:
>
...
>
>  2 Some other process can alter the instruction stream of the stalled
>    process, thereby causing undetectable breakage of the kernel queue
>    that the process is stalled on.  This leads to the worry queue.

Actually no.  The worry queue is used for only one purpose.  When a domain
becomes ready and it has 2 or more domains waiting to get into it, the
first domain trying to get into it is placed on the CPU queue.  The domain
itself is placed on the worry queue (the only place where a non-busy domain
goes on a queue).  In the normal case, the domain on the CPU queue will
call the now ready domain and it will move from the worry queue to the cpu
queue.  In pathological cases (instruction changed, page zapped, meter
zeroed, domain stopped with domain key, long wait for the CPU, etc.) the
worrier will wake up in (I think it was 1/2 a second), and take the next
waiter from the domain(s) on the worry queue and place them on the CPU
queue.  All other queues used the wake everyone waiting logic.


>In EROS, threads queued on a resource are queued in the order that
>they should be woken up.  Because the worry queue as I currently
>understand it violates queue ordering, I'm trying to get rid of it.

The worry queue attempts to maintain queueing order.  Only in the case of
excessive wait time for the CPU will ordering be lost.



>Idea 2: New Internally-Visible Process State
>
>The i386/i486/Pentium/P6 family is so DOG slow at going from user to
>supervisor mode (129+ cycles) that I really would like to avoid doing
>this more than once per syscall.  To avoid it, I have in mind to
>define a new internally visible process state: KernStall.  This state
>is not visible outside the kernel.

We had this state on the 68K.  (The 68K can take a page fault with an
instruction "half executed".  i.e. some of its state modifications have
take place while others could not take place because of the page fault.)  I
believe that this state was visible outside the kernel if, for example, a
segment keeper got the fault, and then used a domain key to the faulting
domain to look at its state.  This is because some of the user-visible side
effects of the instruction had already taken place.  If none of the effects
of the instruction have taken place, you might be able to hide the state
from domain-land programs.

Bill

[prev in list] [next in list] [prev in thread] [next in thread]