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