home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / arch / 8284 < prev    next >
Encoding:
Internet Message Format  |  1992-07-24  |  1.8 KB
  1. Path: sparky!uunet!sun-barr!news2me.ebay.sun.com!exodus.Eng.Sun.COM!appserv.Eng.Sun.COM!ouroborous.Eng.Sun.COM!limes
  2. From: limes@ouroborous.Eng.Sun.COM (Greg Limes)
  3. Newsgroups: comp.arch
  4. Subject: Re: MP interrupt handling  was(Re: Sun 600MP Benchmark Anomaly)
  5. Date: 24 Jul 1992 17:37:43 GMT
  6. Organization: Sun Microsystems, Inc.
  7. Lines: 22
  8. Message-ID: <l70fv7INNgft@appserv.Eng.Sun.COM>
  9. References: <1992Jul20.150259.16021@crd.ge.com> <21b002x91bnp01@JUTS.ccc.amdahl.com> <1992Jul24.133407.18743@cis.uab.edu>
  10. NNTP-Posting-Host: ouroborous
  11.  
  12. In article <1992Jul24.133407.18743@cis.uab.edu> hyatt@cis.uab.edu (Robert Hyatt) writes:
  13. | As near as I can tell, the new SUN MP systems have symmetric hardware where
  14. | any cpu can field an interrupt, but I don't know how a SUN multiprocessor
  15. | arbitrates who (whom?) gets an interrupt when all cpus are interrupt-
  16. | enabled.  Apparently the "big lock" problem currently hangs the suns....
  17.  
  18. We solved it, as usual for the 4.1.2mp product, in the simplest way.
  19. The bus arbiter has a register which tells it which CPU to send
  20. interrupts to, and the software has responsibility for updating it. We
  21. knew that the interrupt dispatch policy would be different for various
  22. versions of the operating system, so we didn't lock it down in the
  23. hardware.
  24.  
  25. Yes, the "big lock" does impact the policy. It means that if one CPU is
  26. inside the kernel, and some other CPU is idle, we really do want the
  27. interrupt to go to the cpu that is inside the kernel.  In practice, we
  28. only have to update the interrupt target register if we receive an
  29. interrupt and fail to acquire the lock; the common case seems to
  30. slide on through the path in minimum time.
  31.  
  32. I think the SunSoft guys did a paper on how they are handling
  33. interrupts in their multithreaded kernel, but I'm not up on that.
  34.