home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / os / vms / 22112 < prev    next >
Encoding:
Internet Message Format  |  1993-01-28  |  4.5 KB
  1. Path: sparky!uunet!UB.com!pacbell.com!decwrl!sdd.hp.com!usc!howland.reston.ans.net!bogus.sura.net!darwin.sura.net!newsserver.jvnc.net!yale.edu!ira.uka.de!math.fu-berlin.de!news.netmbx.de!Germany.EU.net!mcsun!sun4nl!relay.philips.nl!mswe.dnet.ms.philips.nl!hdavids
  2. From: hdavids@mswe.dnet.ms.philips.nl (Henk Davids)
  3. Newsgroups: comp.os.vms
  4. Subject: Image activations, page faults and disk I/O
  5. Message-ID: <1993Jan26.155208.131143@mswe.dnet.ms.philips.nl>
  6. Date: 26 Jan 93 15:52:08 +0100
  7. Organization: Philips Medical Systems Nederland
  8. Lines: 77
  9.  
  10. The following behaviour of VMS has never ceased to amaze me. I would
  11. be very happy if someone with a little insight into the philosophy
  12. that's behind the design of VMS could shed some light on this.
  13. I read somewhere that this subject has been treated (beaten to death?)
  14. on vmsnet.internals some time ago, so I apologize in advance if this
  15. is a waste of bandwidth *).  We are running VMS 5.5-1. 
  16.  
  17. Image activations under VMS are expensive. What's worse is that the
  18. repeated activation of the same image by the same process does not get
  19. cheaper on successive calls. Likewise, multiple activations of a
  20. particular image by many processes are probably just as expensive.
  21.  
  22. Now if you're in a software development shop (like me), many users
  23. execute a lot of relatively simple DCL commands, or short DCL
  24. procedures, in rapid succession. Unfortunately, many DCL commands lead
  25. to the activation of separate images (I can only guess that this setup
  26. was considered the best way when systems were usually short on
  27. memory). The net result of this is, that it's easy to bring VMS to
  28. its knees just by running a simple procedure, for instance one that
  29. results in repeated activations of a few DCL images. Try a loop of for
  30. instance "set process/name=xxx" and compare that to a loop with a
  31. built-in command, like "set default []".
  32.  
  33. A lot of the performance degradation is caused by the page-faults that
  34. the image startup incurs. And these are hard page faults too! In the
  35. past I used to think that unmodified pages of an image file would get
  36. reused, if not for the next activation of the same image by another
  37. process, then at least for multiple activations by the same process.
  38. Well, some of them are...
  39.  
  40. The image activator uses some optimizations for so-called Known Files.
  41. These are images that have been made known to the system by the
  42. INSTALL utility.  This saves a file lookup, and possibly the reading
  43. of the image-header if the image was installed header-resident. But
  44. the actual code pages of the image still have to be read from disk.
  45. When you INSTALL an entry in the Known Files list with the /SHARE
  46. qualifier, a global section will be created for every pure code
  47. section in the image file.  By default, all images that are part of
  48. DCL are installed this way.  Presumably, the image activator should
  49. then map process pages to these global sections. However, that does
  50. not explain all the disk accesses that I see. So, the question is:
  51. does the image activator in this release of VMS really use these
  52. global sections?
  53.  
  54. At image rundown, the pages that contain the image data are moved to
  55. the free list. Normally process pages that are added to the free list
  56. can be reused, if they have not yet been used for something else. I
  57. suspect that image rundown removes the connection between the process
  58. and the image pages, because even on an empty VMS system the hard page
  59. faults keep the disk busy. Why would image rundown go to such trouble?
  60.  
  61. Yet another question. I cannot see a way to defeat VMS here. Some time
  62. ago, someone posted a little program (turbo) that was designed to keep
  63. pages of designated images in memory. Of course, we tried this, but it
  64. didn't work for us as advertised. Or perhaps the basic VMS mechanism,
  65. using global sections, is already working so well that the effect
  66. cannot be measured on our system? Has anybody who tried turbo seen
  67. improvements in performance?
  68.  
  69. Another suggestion: failing a general solution, perhaps DEC could
  70. provide a DCL image in which al lot of these images have been combined
  71. into one in future versions of VMS, for those of us that have plenty
  72. of memory, but not that much bandwidth for page faults? I'm thinking
  73. especially of popular images like SET, DIRECTORY, COPY, RENAME, DELETE
  74. etc.
  75.  
  76. Yet another puzzle: why would image rundown have to deallocate all
  77. your pages in P0 space? Couldn't it just leave the working-set intact,
  78. so that multiple activations of the same image could re-use what was
  79. left over?
  80.  
  81. Suggestions, solutions (and flames :) are welcome.
  82.  
  83.                         Henk
  84.  
  85. *) I never thought that I would have to be so careful not to draw
  86.    flames on comp.os.vms...
  87.