Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!apple!sun-barr!cs.utexas.edu!uunet!mcvax!ukc!dcl-cs!aber-cs!pcg
From: pcg@aber-cs.UUCP (Piercarlo Grandi)
Newsgroups: comp.arch
Subject: Re: Register usage
Message-ID: <979@aber-cs.UUCP>
Date: 1 Jun 89 16:40:10 GMT
Reply-To: pcg@cs.aber.ac.uk (Piercarlo Grandi)
Organization: Dept of CS, UCW Aberystwyth
	(Disclaimer: my statements are purely personal)
Lines: 47

In article <26204@ames.arc.nasa.gov> lamaster@ames.arc.nasa.gov (Hugh LaMaster) writes:

    In article <1RcY6x#64Zq3Y=news@anise.acc.com> lars@salt.acc.com (Lars J Poulsen) writes:
    
    >large a register file is saving and restoring on context switches. While
    >interrupt service routines can ignore this and store only what they
    
    From time to time, I have seen the argument that large register files slow
    down context switches.  Yes and no.  If you are looking at general purpose
    operating systems like Unix, register saves are a very small part of the
    cost of a context switch.

I seem to remember reading that Unix context switch time is 10% the actual
switch, 90% the cost of calling the scheduler to choose the next running
process.

This can be obviated in three ways:

	[1] long timeslices for CPU bound processes (Unix uses 1 second); for
	    io bound processes, process switches tipically occur when the process
	    goes to sleep, so calling the scheduler is almost inevitable.
	[2] a two level scheduler (e.g. MUSS); the short range scheduler only
	    does context switching, always selecting the next process to run
	    as the first in a short queue of very-runnable processes, while the
	    medium term scheduler runs periodically to determine which of
	    the runnable processes should belong to the very-runnable set.
	[3] like [2], but the short term scehduler is done by hardware,
	     e.g. the very old Honeywell 8 contexts-in-a-ring mainframe.

Using [1], the Unix strategy, large register files don't matter a lot, simply
because (as Hugh LaMaster) we are accepting such colossal overheads that
everything pales by comparison.

But large register sets do severely impact the speed of switching in case
[2], less in [3] (where the average cost may be low, because of the multiple
hw contexts for the processes in the very-runnable queue, but variance is
still large when changing its composition).

    Last week I saw an ad for a real time version of Unix with a guaranteed
    response time (switch to kernel to high priority process) of 5
    milliseconds.

A note here: I saw similar ads in the past. 5 ms means 200hz. Booooooo!
-- 
Piercarlo "Peter" Grandi           | ARPA: pcg%cs.aber.ac.uk@nsfnet-relay.ac.uk
Dept of CS, UCW Aberystwyth        | UUCP: ...!mcvax!ukc!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk