home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / os / vms / 22241 < prev    next >
Encoding:
Internet Message Format  |  1993-01-28  |  2.8 KB
  1. Path: sparky!uunet!opl.com!hri.com!spool.mu.edu!howland.reston.ans.net!usc!sdd.hp.com!decwrl!pa.dec.com!engage.pko.dec.com!e2big.mko.dec.com!adserv.enet.dec.com!winalski
  2. From: winalski@adserv.enet.dec.com (Paul S. Winalski)
  3. Newsgroups: comp.os.vms
  4. Subject: Re: Image activations, page faults and disk I/O
  5. Message-ID: <1993Jan27.222442.10344@e2big.mko.dec.com>
  6. Date: 27 Jan 93 22:24:42 GMT
  7. References: <1993Jan26.155208.131143@mswe.dnet.ms.philips.nl>
  8. Sender: usenet@e2big.mko.dec.com (Mr. USENET)
  9. Reply-To: winalski@adserv.enet.dec.com (Paul S. Winalski)
  10. Organization: Digital Equipment Corporation, Nashua NH
  11. Lines: 42
  12.  
  13.  
  14. In article <1993Jan26.155208.131143@mswe.dnet.ms.philips.nl>,
  15. hdavids@mswe.dnet.ms.philips.nl (Henk Davids) asks about the design rationale
  16. behind VMS image activation, in particular, why successive activations of the
  17. same image are not faster than the first, and other such optimizations.
  18.  
  19. The main reason is conservation of physical memory.  The minimum memory
  20. configuration available for the first VAX-11/780s was 256K.  VMS V1 was
  21. designed to run in that configuration.  Keeping track of which image that
  22. a page on the free list belonged to requires additional non-paged data
  23. structures.  Non-paged pool was a precious commodity on 256K VAX systems.
  24. Furthermore, the odds are that on such a system the memory would almost
  25. immediately be scarfed up into another process's working set, so you won't
  26. be able to scavenge those pages, anyway.  This is also why VMS doesn't share
  27. read-only portions of an image by default, but rather requires that you
  28. INSTALL the image first--known image entries consume nonpageable memory, and
  29. in small memory configurations, you're better off not eating up the physical
  30. memory just on the off chance that another user will simultaneously run the
  31. same program.  Cases where the is a payback can be handled by the INSTALL
  32. command.
  33.  
  34. There is an unsupported hack that you can do to speed up image activation.
  35. You write a program that does the following:
  36.  
  37.     1) for each image in a list of images you wish to "turbo-charge":
  38.     2)     call the $IMGACT service to activate the image
  39.     3)     touch each page in the image to fault it into the working set
  40.     4) when all images have been processed, hibernate
  41.  
  42. Install all of the images in the list /SHARE.  Then run the above program in
  43. a process with sufficiently large working set limits to hold all of the images
  44. in physical memory, and with working set adjustment and swapping turned off.
  45.  
  46. This will insure that all of the global pages of the images are always
  47. resident in physical memory, thus, there will be no need to fault them in off
  48. disk when the image is activated and run.  In situations where the same small
  49. set of images is run repeatedly, this can result in vastly improved performance.
  50.  
  51. Of course, this only works on systems where you can afford to have the
  52. physical memory tied down like this.
  53.  
  54. --PSW
  55.