home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / vmsnet / internal / 1212 < prev    next >
Encoding:
Internet Message Format  |  1992-08-29  |  2.7 KB
  1. Path: sparky!uunet!stanford.edu!agate!usenet.ins.cwru.edu!gatech!darwin.sura.net!zaphod.mps.ohio-state.edu!moe.ksu.ksu.edu!deimos.cis.ksu.edu!mccall!infopiz!cmkrnl!jeh
  2. Newsgroups: vmsnet.internals
  3. Subject: Re: VMS tuning for a vaxcluster (LAVC)
  4. Message-ID: <1992Aug27.175326.656@cmkrnl.com>
  5. From: jeh@cmkrnl.com
  6. Date: 27 Aug 92 17:53:26 PDT
  7. References: <2504@mitech.com>
  8. Organization: Kernel Mode Consulting, San Diego, CA
  9. Lines: 42
  10.  
  11. In article <2504@mitech.com>, gjc@mitech.com (George J. Carrette) writes:
  12. > Now. My question is, what good does this do in a VAXCLUSTER environment,
  13. > specifically a LAVC environment? Here a page fault consists
  14. > of both a trip over the ethernet and a trip to disk.
  15. >
  16. > Obviously if a satelite has the pages of an image already in memory,
  17. > then you will winning big, avoiding a trip across the ethernet and everything.
  18. >
  19. > But what about the trip to disk? Is there a way to avoid that?
  20. >
  21. > The LAVC server node may have plenty of free memory, but it may have *never*
  22. > activated any of the images that people on the LAVC's are interested in.
  23. >
  24. > Even if it had activated those images, would there be any optimization
  25. > available? (That is, does the vaxcluster lavc disk server -know- that
  26. > pages from a disk file may already be available in memory?)
  27.  
  28. Not as far as the pager is concerned.  The pager is interested in either finding
  29. a page on the local free or modified page list, or (for global valid pages) in
  30. the working set of another process on the local node, or in the image file.
  31. Again, if we had cluster-wide global sections... even read-only ones...
  32.  
  33. > In VMS 5.4-3 I was using the hack of having all images from SYS$SYSTEM
  34. > and SYS$SHARE also available on the local hard disk. That is a bit hackish,
  35. > so I didn't bother re-doing that for VMS 5.5.
  36.  
  37. Here is another hack, and a partly-baked idea at that (ie I haven't thought
  38. this through; it might not do what you want).  But if your server is all that
  39. memory rich you could turn some of the memory over to a RAM disk driver, copy
  40. the frequently-executed images to the RAM disk, and include the directories
  41. in the RAM disk early in the SYS$SYSTEM: search list.
  42.  
  43. The bad part is that if those same images are activated on the server they're
  44. going to be in memory TWICE on the server -- once in the RAM disk and again as
  45. global pages (or process private pages if they aren't installed shared on the
  46. server).
  47.  
  48.     --- Jamie Hanrahan, Kernel Mode Consulting, San Diego CA
  49. uucp 'g' protocol guru and release coordinator, VMSnet (DECUS uucp) W.G., and
  50. Chair, VMS Programming and Internals Working Group, U.S. DECUS VAX Systems SIG
  51. Internet:  jeh@cmkrnl.com, hanrahan@eisner.decus.org, or jeh@crash.cts.com
  52. Uucp:  ...{crash,eisner,uunet}!cmkrnl!jeh
  53.