home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / unix / internal / 1616 < prev    next >
Encoding:
Internet Message Format  |  1992-07-25  |  4.3 KB
  1. Path: sparky!uunet!auspex-gw!guy
  2. From: guy@Auspex.COM (Guy Harris)
  3. Newsgroups: comp.unix.internals
  4. Subject: Re: getrusage() in SunOS: minflt & majflt meaning (reversed?)
  5. Keywords: confused replacement paging faults
  6. Message-ID: <13747@auspex-gw.auspex.com>
  7. Date: 26 Jul 92 03:51:25 GMT
  8. References: <l71h79INN8v8@estoril.cs.utexas.edu> <l73amqINNaon@estoril.cs.utexas.edu>
  9. Sender: news@auspex-gw.auspex.com
  10. Organization: Auspex Systems, Santa Clara
  11. Lines: 82
  12. Nntp-Posting-Host: auspex.auspex.com
  13.  
  14. >So I guess Sun does have maxflts and minflts backwards...?
  15.  
  16. If you so guess then, unless you're running a SunOS release the source
  17. to which I haven't seen, you guess incorrectly.
  18.  
  19. It bumps "ru_majflt" right after it goes out and does I/O to fetch a
  20. page; it bumps "ru_minflt" if it didn't have to do I/O to fetch the
  21. page.
  22.  
  23. > major faults are "real" page faults that you'd normally think of as
  24. > page faults, i.e., you have to go to swap disk to service it.
  25.  
  26. Well, you don't necessarily have to go to *swap* disk to service it (the
  27. swap disk, of course, may be some *other* machine's disk, as is, for
  28. example, the case on my machine).  The page may come directly from a
  29. file, for example.
  30.  
  31. > Minor faults (supposedly reflected in ru_minflt) are partly
  32. > an artifact of the replacement policy, because the system
  33. > access-protects your pages behind your back, now and then,
  34. > to see if you're still using them.  If you are, it unprotects
  35. > them and lets your program continue, without your program
  36. > knowing about it.
  37.  
  38. Current Suns all have reference bits, managed by hardware.  They don't
  39. have to access-protect the pages to implement software reference bits,
  40. so there shouldn't be minor faults caused by any VAXish reference-bit
  41. simulation.
  42.  
  43. A minor fault will occur if the page in question is in memory,
  44. regardless of whether the fault occurred because the page's translation
  45. was marked invalid (at least in the "MMU driver"s - i.e., hat layers -
  46. with which I'm familiar, it's done by marking the translation invalid,
  47. not by marking it inaccessible) in order to see if you're still
  48. referring to it, or whether it occurred because a translation for it had
  49. yet to be set up in your address space (if a file is mapped into a
  50. process's address space, the system doesn't immediately set up mappings
  51. to all pages from the mapped region of the file that are present in main
  52. memory), or....
  53.  
  54. > I believe that minor faults also include faults caused by
  55. > access protections set at the user level via mprotect(),
  56. > and handled with a user-specified handler set by signal().
  57.  
  58. No.  Such a fault isn't counted as a major *or* a minor fault.  If the
  59. user-specified handler changes protections, or establishes new mappings,
  60. and a fault is later taken on the page and *doesn't* get a protection
  61. fault, that will be counted as a major or minor fault, depending on
  62. whether it required I/O to resolve it or not.
  63.  
  64. > I have two very similar programs, one of which stores data
  65. > in a file and faults it in using an access protection hack.
  66. > The other leaves very similar data in virtual memory, and
  67. > faults it in via the normal virtual memory faulting mechanism.
  68. > Before I run either of them, I evict their working sets from
  69. > memory and file caches by running a routine that just romps
  70. > through a bunch of garbage heap and file data.
  71. > 
  72. > When the former (file-based) program runs, it should get
  73. > ONLY lighweight (user-level) access faults, and possibly
  74. > some lightweight faults from the replacement policy.  The
  75. > disk activity is not done by the virtual memory system,
  76. > but by my access-protection handler which goes through
  77. > the file system.
  78.  
  79. Your access handler goes through the file system.
  80.  
  81. The file system goes through the VM system.
  82.  
  83. Even page faults taken by the file system code that copies data to/from
  84. the kernel address space to which the region of the file to which I/O is
  85. being performed is mapped get recorded as major faults (if the page
  86. wasn't in memory) or minor faults (if it wasn't).
  87.  
  88. > The program that bypasses the VM and goes through the
  89. > file system has lots of majflts and low minflts.
  90.  
  91. Your code to evict pages probably evicted pages from the file, so the
  92. code that read the data from the file system had to fault those pages
  93. back into memory from the file, hence most of the faults were major
  94. faults.  The traps that caused your signal handler to be entered weren't
  95. recorded as faults of any sort.
  96.