Talk:Page fault

message: "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)
replies: text:  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)
replies: text: You mention soft and hard page faults what exactly is the difference? Plugwash 01:38, 16 October 2005 (UTC)
thread_title: bad statement in text

message: 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)
replies: text: 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)
thread_title:  general page fault?! 

message: 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)
thread_title:  The article cleanup 

message: :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)
replies: text: 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)
replies: text:  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)
thread_title:  Possible ambiguous statement 

message: 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)
thread_title:  Possible merger? 

message: 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)
thread_title:  Inaccurate introduction