Page Faults

[souldog]

How concerned should I be if I have say 80 new page faults per update of Task Manager? This an application which has 8 threads collecting data at high speed and shipping it out through a socket. I don't know how top feel about page faults.

[Bob Davis]

Page faults are not necessarily bad. What you're probably thinking of as a really bad thing is an invalid page fault, which most of us remember in those ugly Windows 3.1 error boxes.

(The following is in abstract terms and does not refer to any particular implementation of a memory management scheme, so don't complain if <your_OS> does it a bit differently )

The definition of a page fault has much to do with memory management on the operating system level. Each process has memory space, separated into pages. A page is the smallest chunk of memory that can be allocated to a process. Therefore, each memory address can be thought of a page number plus an offset within that page.

If everything was stored in physical memory, this would not be a problem. However, when you get virtual memory thrown into the mix, things get a lot more complicated. Basically, virtual memory gives you the illusion of a lot more memory, but you can only directly access data that is in physical memory. Since there is more virtual memory than physical memory, not all memory pages are actually held in physical memory at one particular time. If your process tries to access a piece of data, it first must look at what page the data is in. Then, if that page of data is not located in physical memory, it must be read from the disk. This is a page fault.

As you can see, page faults are simply a normal operation of an operating system, so they aren't inherently bad. However, they do indicate that data is being swapped between physical memory and the hard disk, so a lot of page faults can cause performance problems.

[souldog]

Thanks Bob. I guess I was more asking what are these performance penalties. I see them refered to and I refer to them myself, but I have never seem them quantified. I am sure it is OS and platform dependent.

[mdmd]

You can examine page fault operations by running
diskperf - (diskperf -y) - and using performance monitor.
It'll tell you, with a bit of math, if the fault was satisfied
by disk or by memory - you can determine if its a bottle neck
or not.

[souldog]

Thanks MDMD.

Oh No MATH

[mwilliamson]

come on, everybody likes a good equation I would be interested to hear it.

[mdmd]

Alright. But its complicated, complex, and unbelievably difficult and
advanced.

A - B  = C

pagefaultspersec - diskreadspersec = faultstomemorypersec



[edit]
Chapter 12 - Detecting Memory Bottlenecks
in the NT resource kit is a good reference for measuring this stuff.
[/edit]

[souldog]

So if disk reads/second is zero (or small relative to faults/second)then the page then it did not need to go to the disk.


Thanks alot. I do not have a problem

[mdmd]

Right, there's no problem now. But if you're going to distribute the
app on other machines it might have a problem.

Try it on a sqlserver machine and set sqlserver's working memory
set to 1/2 the available ram and see where your page faults go.

Or write a second app that does a VirtualLock() on half the
available ram, then run your app at the same time.

If you're doing 80 page faults per second and they all start going
to disk then you might surpass the # reads per second that a
disk drive can perform and you'll have a bottleneck. The number
in the chapter I listed above suggested it was 40 reads/sec.

Probably never happen, but you can reduce it by maybe providing
you're own allocators for the stl stuff you're using and use
memory from a memory pool of a good size and VirtualLock() it
for the time you need. Maybe look into SetProcessWorkingSetSize()

And thats pretty much all I can say about this There is most
likely a good Richter article in the msdn or online that would
give a good page fault discussion and how to reduce them if
needed.

[souldog]

thanks mdmd. I am not going to distribute this software. I provide the computer as well, but that doesn't mean I am not going to address the problem. What book is that chapter from?

[mdmd]

the NT resource kit. I use the apr2000 msdn. I couldn't find it
in the online version but I didn't really look too hard - just
searched for the title.

[mdmd]

When a thread is running, it spends much of its time translating
addresses and relies on the TLB to make this as fast as possible.
Yet, a single context switch can render the TLB useless. The
address translations of one thread will be incorrect for another
thread unless the second thread is a thread of the same process.
The chances of the thread being from the same process are
remote at best, and even if it were from the same process,
addresses used by the second thread are likely to be entirely
different from those of the first.

Consequently, the buffer is automatically flushed when context
switching between threads on the Intel platform—a hardware
feature. The millions-of-instructions-per-second (MIPS)
implementation of Windows NT does not flush the buffer during
context switches, but it does provide a 36-bit address space that
Windows NT makes use of for this purpose. Windows NT uses the
extra four address bits to identify which process is responsible for
each TLB entry.

I was kind of thinking threads but wasn't sure till I re-read part
of the msdn - where I got the above quote. So maybe the issue
is normal considering you have 8 threads, and won't ever be an
issue. Don't really know. I am curious if there is a way to stop
them anyways.

[EDIT]
Maybe not, TLB I don't think would cause page fault
[/EDIT]

[Mick]

If you really want to understand then put on your glasses,contacts, or beer goggles and start reading all the articles on the virtual-memory manager in Windows NT (the core)....and then start thinking about VirtualAlloc.

You'll enjoy the literature, and be better able to decide the course, and what a page fault really entails. Not for the faint of heart, or anyone with ADD...

Slmming page faults, when your system is getting slammed itself (and not by you of course) can actually improve your performance as your working set size isn't reduced (obvious) but that's a worse case scenario.

My .02 cents...

[Yves M]

If you can, use small static buffers. In one application I was writing, the basic algorithm needed an N^2 matrix of integers where N could be anything up to 1 million. It worked fine with VirtualAlloc, however page faults (and of course memory consumption) were a problem. I changed the algorithm so that it operates only locally on a submatrix at a time, so allocated only an M^2 matrix (where M is something like 500 and fixed, regardless of N). No page faults anymore and even with the extra processing required it was running about 5 times faster.

Then again, as others have said, page faults may come from having a lot of threads and you may not be able to change that. If you avoid allocating dynamic memory regularly in threads (i.e. avoid stuff like std::set, map, list, string, however std::vector is fine) then you can at least minimize the probability of page faults.

[souldog]

Thanks Mick and Yves. Well this is a big thing to really understand. I have started reading the intel architecture manuals and by golly I am going to get it.