Talk:Page fault

From Wikipedia, the free encyclopedia

==bad statement in text "the cause of page faults is not poorly designed processes from user applications. Rather it is the OS's swapping algorithm that is not designed well enough."

These statements reflect a gross misunderstanding on the part of the original author. First, hard and soft page faults are not equally detrimental to performance. Both temporal and spatial locality may be leveraged in code to reduce the effects of hard page faults in an application (which may still generate the less expensive soft faults). Furthermore, code that uses (and consequently touches) less memory will simply generate fewer page faults. Better algorithms in applications (not just the OS) result in better performance. Finally, the OS suffers from a "semantic gap" of sorts, which forces its author(s) to generalize over a wide assortment of possible applications that do well in the average case but may not for any given instance. Only the application developer has the domain knowledge that includes how much memory is expected to be consumed, how long it is needed, whether allocations/deallocations should be made cheaper, how much overhead per allocation is tolerable, how fast memory should be reclaimed by the system, etc. This available knowledge can and should be used to optimize application performance.

The moral in this story: avoid simply blaming the OS for an application's shortcomings. (unsigned comment by 67.160.96.7)

What you are saying is very interesting and I think you should include this information directly in the article instead of just in the discussion. May be you could expand the original sentence. I am thinking of:

"the cause of page faults is not neccessarily poorly designed processes from user applications. Sometimes the OS's swapping algorithm is not designed well enough. Nevertheless better program design such as (insert your knowledge here) can substantially improve..."

--Salzbrot 21:57, 16 August 2005 (UTC)

This also ignores the fact that poorly designed programs doing things like null-pointer-dereferencing DO cause page faults, which the paging algorithm translates into application exceptions and passes up the chain. Kutulu 00:31, 23 February 2006 (UTC)

While this is all very interesting indeed, it has nothing to do with page faults specifically. Since I brought the irrelevant discussion of code optimisation down to a minimum, I didn't see any need to keep the reference to this discussion. There's a very good article on code optimization and another one on memory management that might have need or use for a section on page faults and other MM specific exceptions and CPU states that help code optimisers analyse problems with their code.

--80.127.65.12 08:10, 22 September 2005 (UTC)

You mention soft and hard page faults what exactly is the difference? Plugwash 01:38, 16 October 2005 (UTC)

[edit] general page fault?!

i've seen "general protection fault" and "invalid page fault" but never "general page fault" and i've been using windows for quite a long time. I'm not entirely sure of the difference between the two though so i can't correct the article Plugwash 01:36, 16 October 2005 (UTC)

Yes, I'm pretty sure the original author simply merged the two errors inadvertantly. (Windows doesn't even use either term anymore, too "techie" I guess). Both are related to page faulting, though. I added some more details. Kutulu 00:29, 23 February 2006 (UTC)