Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cornell!uw-beaver!ubc-cs!alberta!calgary!xenlink!blender!bruce
From: bruce@blender.UUCP (Bruce Thompson)
Newsgroups: comp.arch
Subject: Re: Instruction (dis)continuation
Message-ID: <89@blender.UUCP>
Date: 2 Sep 89 03:25:31 GMT
References: <AGLEW.89Aug21205533@chant.urbana.mcd.mot.com> <5990@pt.cs.cmu.edu>
Organization: Some apartment in downtown Calgary
Lines: 68

In article <5990@pt.cs.cmu.edu>, lindsay@MATHOM.GANDALF.CS.CMU.EDU (Donald Lindsay) writes:
	/* discussion about interrupt requests deleted */

> A page fault interrupt isn't like that. The instruction in progress
> cannot go forward: it wants to write to a page that is out on disk
> (or whatever). The interrupt has to be honored at once, and the
> instruction is not completed. The operating system is invoked. The OS
> does good stuff (like disk I/O) and eventually decides to let the
> user program resume.  But resume where in the program? And with what
> register contents, what processor state?
> 
> If the hardware has been designed to do "instruction continuation",
> then the user program will resume somewhere in the middle of the
> offending instruction. If the hardware has been designed for
> "instruction restart", then the program will be resumed at the start
> of the offending instruction. The user-visible result is the same in
> both cases. 
> 

Forgive me if I am re-hashing stuff which has been covered before.

Intruction continuation helps to prevent a condition known as `thrashing'
due to page-faults. An example:

    A machine executes an instruction like the following:
	mov.l	label1, label2

    Assume that the instruction, the source and the destination reside on
different pages in VM. The worst case occurs when both data pages have
been swapped out to disk. The sequence of operations for an `instruction
re-start' machine can occur like this:
	1. fetch the instruction
	2. attempt to fetch the source operand
	3. page fault occurs. Block the process waiting for the page. In
	   most cases, another process is continued until the page has
	   been swapped in.
	4. Re-start the instruction. While waiting for the new page, the
	   page with the instruction has been swapped out. This causes
	   another page fault.
	5. Block the process while the text page is swapped in. Other
	   processes run while waiting.
	6. Re-start the instruction.
	7. goto step 2.

    This sequence can occur for an extremely long period, poossibly
locking up the entire machine, certainly severly degrading performance,
particularly where physical memory is in short supply.

    Where a processor can continue instructions rather than re-start them
the worst-case sequence is:
	1. fetch the instruction
	2. attempt to fetch the source operand
	3. page-fault occurs. Block the process waiting for the new page.
	   Allow other processes to run.
	4. continue instruction
	5. fetch the source operand
	6. attempt to store opreand
	7. page-fault occurs. Block the process until the new page is
	   fetched. Again, other processes are allowed to run.
	8. continue instruction
	9. store the operand

    This demonstrates that on a continuable instruction machine (MC68020
etc.), the paging overhead can be noticably reduced as compared with a
re-start machine.

    From the user's point of view, there will be less paging activity and
better performance on a `continuable' machine.