The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Page faults in background processes

I've got an MFC app that spawns another background copy of itself to do "poor man's parallel programming."

Looking at Task Manager, the number of page faults in the background app is orders of magnitude greater than that of the foreground app.

Is this to be expected? There is plenty of RAM available, so there shouldn't be any paging to disk going on.

And while I'm at it, what can I do to reduce page faults in general, since they slow down performance, or so I'm told. Are there any sources of information people can recommend? Google provided lots of hits, but mostly complaints. :)

I normally leave the dark arts of Windows internals well alone, but this has piqued my curiosity.
Defaulter
Thursday, August 07, 2008
 
 
Is it actually performing a different task than original process, such as reading/writing files?  File I/O on Windows is based on the virtual memory system (the file I/O cache and virtual memory management are tightly integrated).
mwb
Thursday, August 07, 2008
 
 
What are you running it on? A desktop or server OS?

Client versions of Windows (XP, Vista, 2000 Workstation) prioritise foreground tasks for timeslices and memory allocation, so you'd get more page faults on a background process because it will have a harder time getting memory allocated, and will likely get paged out quicker and harder.

You can change this setting, BTW, and make a desktop OS prioritise background services and a server OS do the reverse (in fact, if you use a server OS as your desktop OS, as I do with Windows Server 2008, then you should do this to keep your apps responsive).
.NET Guy
Thursday, August 07, 2008
 
 
"Page faults" generally mean you're using virtual memory - your actual RAM is being shared amongst too many processes, so data is getting paged out to the hard drive and back in again. That takes time, which is why page faults cause software to slow down. (In practise, Windows is usually smart enough to keep things running fast enough.)

Problem: You're using more RAM than is actually installed in your machine
Solution: If you can't work it out, please beat yourself to death with your computer.  :)

Also, depending on what you're doing with your "background" process, there's a good chance that the "foreground" process is running at a higher priority. This can happen for many reasons, including user interaction because Windows prioritises the application that the user is directly involved with. (There's a lot more detail to it, of course.)

Therefore, if Windows sees one process getting used and another is "background", it'll pick the background process to page out because it won't be running as much.

Problem: The background processes are getting less run time than the foreground process
Solution: Ponder the definition of "background" until you understand that this is a good thing

For extra credit, count the number of CPU cores in use, measure the actual processor usage required, check for blocking operations, and determine if you're achieving anything at all. Unless your have multiple cores and/or frequently block waiting for data to process, parallelising your software will have limited benefit.

For example, finding prime numbers just takes raw clock cycles. If you have a single core and two processes, you add synchronisation and process-switching overhead but don't add the resource you need - those clock cycles - so the result will be a slower system. If you add a second core then you have added the necessary resources, so a second process will make the task happen roughly twice as fast. If you need to read and write files, then one process can be accessing the hard drive while the other is working, so even on a single processor system you can get benefits from having two processors sharing the work. But you have to measure, to make sure you're getting an overall benefit, even if individial processes don't do what you expect.

Thursday, August 07, 2008
 
 
I don't know the specifics of how Windows handles things, but a number of recent UNIX varieties handle forks by simply duplicating the current processes page tables in the new process and marking all the page as Copy on Write (CoW). As either process (parent or child) makes changes to it's address space, the corresponding pages in the child process are replaced with newly allocated copies of the pages (prior to modification) from the parent's address space. I suppose that all those page faults might be counted only against the child process, and thus account for the activity you are seeing.
Jeffrey Dutky Send private email
Thursday, August 07, 2008
 
 
It's a desktop app, and it's doing the same thing as the foreground process, just on different files, and there's nowhere near enough RAM being used to run out of physical RAM.
Defaulter
Friday, August 08, 2008
 
 
+mwb

The file cache and virtual memory system use the same memory pool.  Page faults could be just loading/mapping DLLs into RAM, file I/O going on, etc.

I would expect you'd have a lot of page faults when the app first started and then they would lessen as the working set gets established.
Doug
Friday, August 08, 2008
 
 
> It's a desktop app ... doing the same thing as the foreground process ... on different files

Are the applications processing a relatively-infinite size of data in the files? For example, if the machine has 2GB RAM, are the applications reading and/or writing more than 2GB of data from and/or to the disk?
Christopher Wells Send private email
Friday, August 08, 2008
 
 
@Christopher Wells,

Yes, they can do. But not always. I'll check if there's a correlation. Certainly the files are closed and finished with (memory deallocated) before other files are loaded in.

What is your reasoning? I'm intrigued.
Defaulter
Saturday, August 09, 2008
 
 
Without seeing actual stats in terms of memory used, page faults over time etc, it's hard to say if you really have a problem. Page faults are perfectly normal, they don't really indicate any kind of 'fault' as I'm sure you're aware. They happen when an attempt is made to access an address in the address space of a process and there's no page of memory mapped there. The page fault triggers the VMM to go look for where the page actually is (ie paged out to disk, somewhere else in the address space etc).

You'll likely get quite a few page faults even in a tightly-memory-managed app, because Windows is very aggressive about paging out RAM that doesn't look like it's being used, irrespective of the ginormous amounts of physical RAM you might have. It's a legacy of the days when Windows could fit in 4MB and still run two or three programs.

That you get more faults with a background process makes sense, because - on a desktop OS - the foreground app will get more time slices and hence a higher priority with the VMM.

So unless there's a pathologically large number of faults, which could be indicative of a leak or some kind, I wouldn't be too worried, although just wanting to understand why it's happening is reason enough to keep looking.

Best of luck :-)
.NET Guy
Sunday, August 10, 2008
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz