home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / arch / 8298 < prev    next >
Encoding:
Internet Message Format  |  1992-07-25  |  3.5 KB
  1. Path: sparky!uunet!sun-barr!news2me.ebay.sun.com!exodus.Eng.Sun.COM!nonsequitur!narad
  2. From: narad@nonsequitur.Eng.Sun.COM (Chuck Narad)
  3. Newsgroups: comp.arch
  4. Subject: Re: MP interrupt handling
  5. Date: 25 Jul 1992 00:21:45 GMT
  6. Organization: Sun Microsystems
  7. Lines: 64
  8. Distribution: world
  9. Message-ID: <l717kpINN2ou@exodus.Eng.Sun.COM>
  10. References: <JIM.92Jul24155432@hunter.cs.strath.ac.uk>
  11. Reply-To: narad@nonsequitur.Eng.Sun.COM
  12. NNTP-Posting-Host: nonsequitur
  13.  
  14. In article 92Jul24155432@hunter.cs.strath.ac.uk, jim@cs.strath.ac.uk (Jim Reid) writes:
  15. >In article <l6tucvINNbqt@appserv.Eng.Sun.COM> limes@ouroborous.Eng.Sun.COM (Greg Limes) writes:
  16. >
  17. >   | So, how many processors can take and service interrupts?  
  18. >
  19. >   Two answers, as usual ;-)
  20. >
  21. >   First answer: All CPUs can accept and service interrupts,
  22. >   without regard to which CPU initiated the action that
  23. >   eventually triggered the interrupt. The same chip that handles
  24. >   MBus arbitration handles distribution of the interrupts; an
  25. >   internal register tells it which CPU gets them.
  26. >
  27. >   Second answer: Only one CPU at a time can receive interrupt
  28. >   requests from devices in the system, and the software design of
  29. >   the 4.1.2mp kernel requires that device interrupt service
  30. >   routines execute within the single lock, so only one CPU at a
  31. >   time will be inside interrupt service routines.
  32. >
  33. >So does this mean that this "symmetrical multi-processor SunOS" isn't
  34. >really what it claims to be? If only one CPU at a time can be executing 
  35. >interrupt service code, what we've got is an OS with one dedicated
  36. >(but not fixed) I/O processor.
  37.  
  38. The fact that only one processor at a time can recieve interrupts from
  39. devices does not imply (as you believe) that only one processor can
  40. service interrupts concurrently.
  41.  
  42. Interrupts are divided into three classes; directed, undirected, and
  43. broadcast.  Directed interrupts include a mechanism where any processor
  44. can send any other processor interrupts at each level, which can be
  45. used (along with mailboxes in memory) to dispatch cross-calls.
  46. Undirected interrupts include all interrupts from I/O devices; at any
  47. time, all undirected interrupts are steered to a selected processor.
  48.  
  49. In order to make a system like this truly symmetric (including service
  50. of I/O interrupts) there are several choices; one is that a processor
  51. can take an interrupt, relinquish the "interrupt servicer" status to
  52. another processor, then proceed with the service routine.  Another is
  53. to have the current holder of that status run a very lightweight
  54. dispatch routine, where it determines the source of the interrupt,
  55. selects the best candidate servicer by some algorithm (e.g. least busy,
  56. interrupt thread affinity to warmer cache, etc) and dispatches the
  57. interrupt to a selected servicer via a cross-call interrupt.  Call that
  58. lightweight dispatch routine "microcode" if you prefer; I like to call
  59. it that just to irritate our OS programmers :-)
  60.  
  61. So the fact that the interrupts are steered to a single processor at
  62. any time does not preclude the entire *system* (including "microcode")
  63. from being fully symmetric in the hardware and software.
  64.  
  65. This approach was found to be much more flexible, as well as being far
  66. simpler to implement/ debug/prove than any hardware dispatch mechanism,
  67. and does not lock the OS to dealing with any particular algorithm that
  68. was carved in silicon.
  69.  
  70. That's about all I can say without stepping over the lines of what has
  71. been stated publically.
  72.  
  73. chuck/
  74.  
  75. Disclaimer:  speaking for myself; the above does not neccessarily
  76. reflect the opinions of my employer.
  77.  
  78.