home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / arch / 8344 < prev    next >
Encoding:
Text File  |  1992-07-26  |  1.5 KB  |  40 lines
  1. Newsgroups: comp.arch
  2. Path: sparky!uunet!iWarp.intel.com|ichips!ichips!glew
  3. From: glew@pdx007.intel.com (Andy Glew)
  4. Subject: Re: Scheduling in Shared Memory Multiprocessor Systems
  5. In-Reply-To: david@elroy.jpl.nasa.gov's message of Fri, 24 Jul 1992 18:32:13 GMT
  6. Message-ID: <GLEW.92Jul26201316@pdx007.intel.com>
  7. Sender: news@ichips.intel.com (News Account)
  8. Organization: Intel Corp., Hillsboro, Oregon
  9. References: <1992Jul15.040528.16289@access.usask.ca> <GLEW.92Jul23215649@pdx007.intel.com>
  10.     <1992Jul24.183213.9699@elroy.jpl.nasa.gov>
  11. Date: Mon, 27 Jul 1992 04:13:16 GMT
  12. Lines: 26
  13.  
  14.     >Gould PN machines used a simple affinity algorithm:
  15.     >    The run queue was divided into 32 priorities (each a single chain)
  16.     >    - the classic BSD run queue.
  17.     Isn't this an artifact of the Vax architecture having 32 hardware
  18.     queues and instructions to manipulate them?  Have most BSD vendors
  19.     kept this structure or gone with something radically different?
  20.  
  21. I wasn't aware of any limitation on VAX queues.
  22.  
  23. What was convenient, however, was keeping a bit per queue indicating
  24. occupancy. 32 bit words.  That way simple tests against 0 and FFS
  25. could be used to query the run queue.
  26.  
  27. At one occasion we did try > 32 queues, but the overhead wasn't worth it.
  28.  
  29. With 64 bit integers common, 64 run queues will be likely.
  30. --
  31.  
  32. Andy Glew, glew@ichips.intel.com
  33. Intel Corp., M/S JF1-19, 5200 NE Elam Young Pkwy, 
  34. Hillsboro, Oregon 97124-6497
  35.  
  36. This is a private posting; it does not indicate opinions or positions
  37. of Intel Corp.
  38.  
  39. Intel Inside (tm)
  40.