Talk:Page fault

This is the talk page for discussing improvements to the Page fault article.
This is not a forum for general discussion of the article's subject.

Put new text under old text. Click here to start a new topic.
New to Wikipedia? Welcome! Learn to edit; get help.

Article policies

Find sources: Google (books · news · scholar · free images · WP refs) · FENS · JSTOR · TWL

Computing: Software Low‑importance

	This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.ComputingWikipedia:WikiProject ComputingTemplate:WikiProject ComputingComputing articles
Low	This article has been rated as Low-importance on the project's importance scale.
	This article is supported by WikiProject Software (assessed as Low-importance).
	This article is supported by Computer hardware task force (assessed as Low-importance).

bad statement in text[edit]

"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)[reply]

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)[reply]

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)[reply]

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

There also seems to be a lot of confusion in this article between the terms page fault and general protection fault. The two are distinct, and when it comes down to memory accesses on x86, page faults are used for paging based systems and general protection faults are used for segmentation based accesses. (GPFs are used for other things as well, however.) I've started to clean up a lil bit of this, but there's still some work to be done. (Specifically, if an access to a page which does not conform to the page's permission attributes occurs, a page fault and *not* a general protection fault is raised.) Skywing 19:48, 16 July 2007 (UTC)[reply]

general page fault?![edit]

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)[reply]

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)[reply]

The article cleanup[edit]

Over the years lot of information is duplicated because of some authors are from windows and some are from Linux. I simplified the articale and hope created smooth flow. I have not touched the performance section yet and leave it to others to enhance or merge with the rest of the contents. mlpkr 05:19, 28 May 2007 (UTC)[reply]

Possible ambiguous statement[edit]

Recent versions of Windows replace all the minor faults and other hardware-generated fault errors with a single, less technical error simply stating that "this program must close".

The use of the word minor in here seem's like it might cause some confusion. The sentence appears to be referencing minor segmentaion and protection faults but from the way it is written it looks like it might be talking about soft page faults, which I'm pretty sure don't cause the program to close. I'm not quite sure how to reword this yet, also it might be a good idea to mention what a major fualt will cause (BSOD or Reboot?). It would be nice if someone with a better understanding of Windows Virtual Memory could look at this. Lt pau 05:32, 14 July 2007 (UTC)[reply]

I totally agree with the comment, yes someone with windows knowledge could reword it. Perhaps information about this windows fault may go into protection fault page instead of here. mlpkr 13:32, 16 July 2007 (UTC)[reply]

I've put a lil bit of more useful information here relating to Windows and its handling of page faults, and how they are exposed to programs. Anyone can easily expand on it further by perusing the Structured Exception Handling documentation at MSDN. Skywing 20:05, 16 July 2007 (UTC)[reply]

Possible merger?[edit]

My page, SPCMDCON.SYS, is on the brink of deletion on the grounds of needing a merger. I was hoping you'd be willing to help me? Gp75motorsports 15:02, 19 September 2007 (UTC)Gp75motorsportsGp75motorsports 15:02, 19 September 2007 (UTC)[reply]

I don't really see what this has to do with the page fault article and hence there doesn't really seem to me to be a good reason to merge the two? I would vote for removing the merge notice at the top. (Lots of crashes are initially detected through a page fault. Having the page fault article link to or merge with every crash in the world that is reported via a page fault is highly impractical to say the least.) Skywing 02:47, 22 September 2007 (UTC)[reply]

Inaccurate introduction[edit]

The opening sentence is misleading, and I believe overly specific in one case. "...A page is a fixed-length block of memory that is used as a unit of transfer between physical memory and external storage like a disk..." is not untrue, but suggests that this is all that the page paradigm is for, which it isn't. Furthermore "...a page fault is an interrupt ... when a program accesses a page that is mapped in address space, but not loaded in physical memory." This wouldn't include the copy-on-write technology, which is mentioned later in the article, and again suggests that page faults are only about swapping. AngusCA (talk) 17:45, 24 March 2009 (UTC)[reply]

I've made a minor clarification to the article. It's only in Windows Vista that page faults began to be referred to as "hard faults"; Windows XP and earlier versions still refer to them as page faults. --Special Operative MACAVITY^{Debrief me} 12:14, 31 July 2011 (UTC)[reply]

Too reliant on assumed knowledge and jargon[edit]

This page fails to communicate a clear, straightforward definition/explanation of what a page fault is. This is a highly technical subject but the article still needs to attempt to address a general reader and should assume no prior knowledge. — Preceding unsigned comment added by Hutak (talk • contribs) 07:30, 3 October 2011 (UTC)[reply]

Particularly that first sentence. Paradox

Hello! This edit makes the lead section slightly more understandable; beside that, page faults are what they are, sorry, and "dumbing" it further down would hardly make the whole thing more approachable. Furthermore, explaining all other concepts related to page faults in this lead section simply wouldn't make sense; instead of doing that, anybody should be able to grasp the whole thing rather easily by following the links in the lead section. — Dsimic (talk | contribs) 06:45, 18 February 2015 (UTC)[reply]