home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / vmsnet / internal / 1190 < prev    next >
Encoding:
Internet Message Format  |  1992-08-25  |  3.0 KB
  1. Path: sparky!uunet!usc!zaphod.mps.ohio-state.edu!moe.ksu.ksu.edu!deimos.cis.ksu.edu!mccall!infopiz!cmkrnl!jeh
  2. Newsgroups: vmsnet.internals
  3. Subject: Re: global vs. private pages on the FPL (was: VMS Tuning)
  4. Message-ID: <1992Aug25.122200.644@cmkrnl.com>
  5. From: jeh@cmkrnl.com
  6. Date: 25 Aug 92 12:21:59 PDT
  7. References: <06D94B115A9F822B58@MAX.U.WASHINGTON.EDU>
  8. Organization: Kernel Mode Consulting, San Diego, CA
  9. Lines: 49
  10.  
  11. In article <06D94B115A9F822B58@MAX.U.WASHINGTON.EDU>,
  12.  DEREK@U.WASHINGTON.EDU writes:
  13. > When a
  14. > process "gives" up a page, the memory is placed onto either the free page
  15. > list, or the modified page list.  Process-private pages are placed at the
  16. > head of the free page list, while system-owned pages are placed at the
  17. > tail.  (By "system-owned pages" I mean pages which are part of an installed
  18. > image, such as the DIRECTORY utility.)
  19.  
  20. This is not correct.  Unmodified pages that are removed from a working set by
  21. working set replacement are put at the end of the FPL, not the beginning, and
  22. it doesn't matter whether they were process-private or global pages. (Please
  23. don't call the latter "system-owned", that sounds as though you mean that
  24. they're part of the system working set.  The system working set is handled
  25. just like a process working set as far as page replacement is concerned.)
  26.  
  27. A global page is of course not put on the FPL at all unless it's been pushed
  28. out of the working sets of *all* of the processes that had referenced it.
  29.  
  30. Modified pages go to the end of the modified page list.  When they reach the
  31. top of the MPL and are written back to disk, they then go to the end of the
  32. FPL.
  33.  
  34. Pages are put at the top of the free page list when they are released at
  35. image rundown, or, more generally, by deletion of the virtual address space
  36. that describes them.  In the case of global pages, this happens when no more
  37. processes are mapped to the relevant global section.  So, yes, what you call
  38. "system owned" pages *can* be released to the top of the FPL.  It all depends
  39. on why the pages are being released -- working set replacement (to make room
  40. for a newly-faulted-in page when the working set is full) or deletion of the
  41. virtual address space.
  42.  
  43. > When a process needs a new page,
  44. > it takes it from the head of the free page list.  Thus, the system-owned
  45. > pages are more likely to "survive" if the free page list is relatively
  46. > large.
  47.  
  48. Right idea, wrong detail.  The pages in on the FPL that contain useful data are
  49. more likely to survive.  It doesn't matter whether they were process-private or
  50. global pages.
  51.  
  52. Lots of well-known "authorities" on VMS get these details wrong, repeatedly, in
  53. print.  Professional courtesy prevents me from naming names.
  54.  
  55.     --- Jamie Hanrahan, Kernel Mode Consulting, San Diego CA
  56. uucp 'g' protocol guru and release coordinator, VMSnet (DECUS uucp) W.G., and
  57. Chair, VMS Programming and Internals Working Group, U.S. DECUS VAX Systems SIG
  58. Internet:  jeh@cmkrnl.com, hanrahan@eisner.decus.org, or jeh@crash.cts.com
  59. Uucp:  ...{crash,eisner,uunet}!cmkrnl!jeh
  60.