Differences between version 2 and previous revision of PageFault.
Other diffs: Previous Major Revision, Previous Author, or view the Annotated Edit History
Newer page: | version 2 | Last edited on Thursday, March 25, 2004 12:04:00 am | by AristotlePagaltzis | Revert |
Older page: | version 1 | Last edited on Wednesday, March 24, 2004 10:12:20 pm | by StuartYeates | Revert |
@@ -1 +1,8 @@
-In
VirtualMemory systems a PageFault occurs when
a process reads or writes
to a page
of memory which is not
in memory. If
the page is not in memory because
it's been swapped
to the HardDrive then
the process must be suspended until
the page can be retreived from disk
.
+A PageFault is triggered in
VirtualMemory systems by
a process's failed attempt
to access an address in memory.
+
+Such failure may occur for
a number
of reasons:
+
+* Most frequently, the page in which the address lies has not been mapped to physical
memory by the OperatingSystem. Most of the time, the content of the page has been written to HardDisk, and the page is unmapped for this process and mapped in another's address space
which needs more memory. This
is called __swapping out__ the page
in question. The PageFault handler in the [Kernel] resolves this situation by swapping out another page in a currently dormant process, loading the content of the current process's swapped out page into the now free page, and mapping this page into the process's address space at the right location. Then, it resumes the process which was interrupted by the PageFault, which doesn't notice nary a thing of these happenings. To it, it appears as if its
memory access succeeded without a hitch
. %%% %%%
+* Sometimes, again,
the page is not mapped to physical memory. However,
in this case no
memory was ever allocated to
it at that stretch in its address space. This type of PageFault is known as a SegmentationFault. %%% %%%
+* Similarly, a SegmentationFault may happen if the process tried to write to read-only or execute-only memory, or to read from execute-only memory. %%% %%%
+* Sometimes, attempting to write to a read-only page is actually part of normal operation. In particular, creating a new process on [Unix] systems happens by duplicating the running process by way of the fork(2) system call. In order to avoid excessive fork(2) runtime cost of yore, modern [Kernel]s don
't copy the entire memory used by the forked process, but rather implement transparent CopyOnWrite by marking all the pages shared between several processes as read-only. When a process [PageFault]
s by trying
to write to such a shared page,
the processes are given individual copies of that page, marked read-write this time. Again
the process which was interrupted by
the PageFault is resumed and continues execution as if its memory access succeeded in the first place
.