Path: utzoo!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!cs.utexas.edu!sun-barr!newstop!sun!amdahl!mat
From: mat@uts.amdahl.com (Mike Taylor)
Newsgroups: comp.arch
Subject: Re: Context switching on RISC chips
Keywords: Context Switching, Interrupts, MIMD Architecture
Message-ID: <7fWJ02qY7aoo01@amdahl.uts.amdahl.com>
Date: 2 Jan 90 17:39:42 GMT
References: <3167@iitmax.IIT.EDU> <14007@pur-ee.UUCP>
Organization: Amdahl Corporation, Sunnyvale CA
Lines: 20

In article <14007@pur-ee.UUCP>, hankd@pur-ee.UUCP (Hank Dietz) writes:
> 
> 6) Since nobody builds uniprocessors anymore (;-), NEVER interrupt a
>    processor:  simply let another processor which happens to be free at that
>    moment (or the next processor to become free) handle the interrupt.
> 
> Number 6 is the really interesting one.
> 
A slight variation on this is used by some mainframe operating systems - in
a multiprocessor only one processor may be enabled for I/O interruptions. The
OS will enable another processor if the interrupt load on the enabled processor
reaches a certain threshold (and so on).  Of course, any processor can start 
an I/O operation. A nice side-effect is that the enabled processor can test
for pending interrupts when it finishes interrupt processing and handle the
next one in the queue without bothering to process switch. This batching effect
increases performance further.
-- 
Mike Taylor                               ...!{hplabs,amdcad,sun}!amdahl!mat

[ This may not reflect my opinion, let alone anyone else's.  ]