Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ncar!asuvax!cs.utexas.edu!uunet!dg!rec
From: rec@dg.dg.com (Robert Cousins)
Newsgroups: comp.arch
Subject: Re: Context switching on RISC chips
Keywords: Context Switching, Interrupts, MIMD Architecture
Message-ID: <249@dg.dg.com>
Date: 3 Jan 90 16:51:01 GMT
References: <3167@iitmax.IIT.EDU> <14007@pur-ee.UUCP> <7fWJ02qY7aoo01@amdahl.uts.amdahl.com>
Reply-To: uunet!dg!rec (Robert Cousins)
Organization: Data General, Westboro, MA.
Lines: 39

In article <7fWJ02qY7aoo01@amdahl.uts.amdahl.com> mat@uts.amdahl.com (Mike Taylor) writes:
>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 can bring about unacceptable performance degradations under some 
circumstances. A number of fully symmetric operating systems allow any
processor to field an interrupt from any peripheral (DG/UX does). One
of the reasons for this is that single threading interrupt service 
(which is what you are talking about) introduces two sets of delays:
The first is when a peripheral must wait longer on average for interrupt 
service which reduces throughput and the second is when the sleeping task 
may not wake up until a cross-processor interrupt occurs.  Both of these are 
statistical problems that occur to some degree on all MP OSs.
However, if you do the queueing computations, it is indeed preferable
to allow multiple CPUs to handle interrupts.  However, this does not
mean that batching of interrupt processing is a bad idea.  Just the
opposite.  When a CPU completes one ISR, it should be able to enter
another without penalty.  Conclusion: administring an interrupt policy
for a high performance multiprocessor is more complex than normally
considered.

Robert Cousins
Dept. Mgr, Workstation Dev't.
Data General Corp.

Speaking for myself alone.
which reduces thoughput