From: guy@Auspex.COM (Guy Harris)
Newsgroups: comp.unix.internals
Subject: Re: getrusage() in SunOS: minflt & majflt meaning (reversed?)
Keywords: confused replacement paging faults
Date: 26 Jul 92 03:51:25 GMT
Organization: Auspex Systems, Santa Clara

>So I guess Sun does have maxflts and minflts backwards...?

If you so guess then, unless you're running a SunOS release the source
to which I haven't seen, you guess incorrectly.

It bumps "ru_majflt" right after it goes out and does I/O to fetch a
page; it bumps "ru_minflt" if it didn't have to do I/O to fetch the
page.

> major faults are "real" page faults that you'd normally think of as
> page faults, i.e., you have to go to swap disk to service it.

Well, you don't necessarily have to go to *swap* disk to service it (the
swap disk, of course, may be some *other* machine's disk, as is, for
example, the case on my machine).  The page may come directly from a
file, for example.

> Minor faults (supposedly reflected in ru_minflt) are partly
> an artifact of the replacement policy, because the system
> access-protects your pages behind your back, now and then,
> to see if you're still using them.  If you are, it unprotects
> them and lets your program continue, without your program
> knowing about it.

Current Suns all have reference bits, managed by hardware.  They don't
have to access-protect the pages to implement software reference bits,
so there shouldn't be minor faults caused by any VAXish reference-bit
simulation.

A minor fault will occur if the page in question is in memory,
regardless of whether the fault occurred because the page's translation
was marked invalid (at least in the "MMU driver"s - i.e., hat layers -
with which I'm familiar, it's done by marking the translation invalid,
not by marking it inaccessible) in order to see if you're still
referring to it, or whether it occurred because a translation for it had
yet to be set up in your address space (if a file is mapped into a
process's address space, the system doesn't immediately set up mappings
to all pages from the mapped region of the file that are present in main
memory), or....

> I believe that minor faults also include faults caused by
> access protections set at the user level via mprotect(),
> and handled with a user-specified handler set by signal().

No.  Such a fault isn't counted as a major *or* a minor fault.  If the
user-specified handler changes protections, or establishes new mappings,
and a fault is later taken on the page and *doesn't* get a protection
fault, that will be counted as a major or minor fault, depending on
whether it required I/O to resolve it or not.

> I have two very similar programs, one of which stores data
> in a file and faults it in using an access protection hack.
> The other leaves very similar data in virtual memory, and
> faults it in via the normal virtual memory faulting mechanism.
> Before I run either of them, I evict their working sets from
> memory and file caches by running a routine that just romps
> through a bunch of garbage heap and file data.
> 
> When the former (file-based) program runs, it should get
> ONLY lighweight (user-level) access faults, and possibly
> some lightweight faults from the replacement policy.  The
> disk activity is not done by the virtual memory system,
> but by my access-protection handler which goes through
> the file system.

Your access handler goes through the file system.

The file system goes through the VM system.

Even page faults taken by the file system code that copies data to/from
the kernel address space to which the region of the file to which I/O is
being performed is mapped get recorded as major faults (if the page
wasn't in memory) or minor faults (if it wasn't).

> The program that bypasses the VM and goes through the
> file system has lots of majflts and low minflts.

Your code to evict pages probably evicted pages from the file, so the
code that read the data from the file system had to fault those pages
back into memory from the file, hence most of the faults were major
faults.  The traps that caused your signal handler to be entered weren't
recorded as faults of any sort.