CS355 Sylabus

Page Fault

The Paging Technique is the second technique that relies its success on the execution locality behaviour of computer programs
Programs usually consists of many loops and the program runs a long time in one loop.
While the program is inside one loop, it only need instructions that comprises that loop and do not need other instructions.
Hence, only a few program pages need to be present in the memory while the program is executing in some loop.
When the program leaves that loop and executes inside another loop, the computer will fetch other pages from disk and replace those pages in memory from the previous loop
What is still missing in the discussion on paging is the mechanism used to fetch a page that is needed to complete the execution of the current instruction (the page is needed because it contain the current instruction or a memory variable referenced by the current instruction).
The mechanism consists of two parts:
- A detection method to determine whther the page containing the instruction or variable is presently in memory or not
- If the page is not present, then execute a program (subroutine) to fetch the page from disk.
Detecting if a page needed by the CPU is present in memory:
- Recall that the page table entries contains a present bit:
- The page is present in memory if the present bit for that page is ONE (1), and otherwise, the present bit is ZERO.
- We can easily determine if a page needed by the CPU is present in memory or not.
A jargon:
- When the CPU tries to access a program location from a page that is not present in memory, we say that a page fault occurs.
Intro to fetching a page from disk:
- When a page fault is detected (using the present bit in the page table), the program cannot continue execution until the needed page is read in from disk.
- Note that the page is stored on disk and must be read from disk and the disk is sloooooow....
- Note that this situation is the same as when the program would read data from disk to perform processing.... (the effect is that the program cannot continue because it must wait for the IO transfer !!!)
- So we know how to handle this efficiently !!!
- DMA !!!
Now, as you know from the discussion on IO communication, when a program performs an IO operation (like a disk read operation), the currently running program is stopped and its PCB (process control block) is deleted from the Ready Queue (and inserted into the device (DMA) queue).
In order to stop a program so that it can be restarted later from the point where it is stopped, you need to save the context information (see: click here)
Afterwards, another (ready) program is run (while the DMA performs the IO transfer on behave of the stopped program).
In order to fully understand what happens during a page fault, you will need some more background knowledge:
- The MMU contains many page table data structures (for many different programs).
- The MMU has a special "current page table" register that points to the page table used to translate program addresses from the current program:
- Each page table is set up by the Operating System.
- Initially, the present bit of all entries are ZERO and the location of the pages on disk are initialized (the Operating System allocates the pages on disk and set up the location in the page table)
The following figure shows all the components of a computer system that uses paging:
- This figures shows 3 running program in the system.
- The current program executing on the CPU is the program at the head of the Ready Queue
- The current page table register in the MMU must also points to the page table used by the current program.
  That page table will translate program address into memory addresses and these memory address will be value in the memory frames that are occupied by pages of the current program.
- The figure above shows a memory access when the page containing the requested program address is present in memory.
- If you look carefully in the OS, you will see there is a page fault interrupt handling routine.
  That's the magic that makes paging work !
Recall from the discussion above, that a program address may cause a page fault (the page containing that program address is not present in memory).
If a page fault occurs, the page must be read from disk by the DMA.
While the DMA is busy transfering the page for the current running program, the current running program must be stop (save context !) and moved to the DMA queue - just like in the case of a IO operation, in fact, it is doing an IO operation...
But unlike the disk read operation where the current running program calls a read routine inside the Operating System that will save the context (see click here), the page fault happens "suddenly" - unplanned.
Give the above statement a bit of thought:
- when the program performs a read operation, we can (plan ahead and) write some code in the OS_Read routine to save the context of the program.
- but in a page fault (unplanned), we cannot plan ahead (because we do not know when a page fault will happen).
- Have we been checkmated ???? Fear not, humans are pretty ingenious...
The "making the CPU do something unplanned" problem has been solved before !!!!
If you don't recognize this problem, see this syllabus webpage: click here
The MMU uses the Interrupt mechanism to make an unplanned page fetch operation !!!
The following set of figures shows what will happen when a page fault occurs:
- When the MMU detects a page fault (present bit of the page is ZERO), it raises the Interrupt signal:
- When the CPU detects the Interrupt signal before its instruction fetch cycle completes, it aborts the instruction cycle and acknowledge the interrupt:
  (Note that while the CPU is executing an instruction, it very hard to abort (need lots of extra circuitry). But it is very simple to abort while it has not done fetching).
- The MMU will send out its interrupt vector (it uses vector interrupt, see: click here) and the CPU will execute the page fault (interrupt) handling routine within the Operating System.

From the discussion on "interrupt handling routines", you should be able to guess what the code the page fault interrupt handling routine will look like.

I will - again - only give you the psuedo code for the page fault handler. You need to take the graduate course in "Operating System" to get all the details.

The psuedo code for the page fault handler is as follows: (very similar to the handler for the disk IO; but need to update the page tabel in the MMU !!!)

(The page fault interrupt is generated by the MMU)

0. Acknowledge Interrupt (CPU will receive vector from the MMU and call the Page fault interrupt handler): ============================================================ 1. Save the context from the CPU into the head of the Ready Queue // This is needed because the current program is no longer // ready to run 2. Perform a disk read operation using the location on disk information in the page table. 3. Remove the head of the Ready Queue and insert it into the DMAQ queue 4. DMAQ's PCB.pageFault = TRUE; // PCB must contain // a variable to indicate // if request was a pagefault 5a. Update current page table register of MMU to point to: the page table of the program that at the head of the Ready Queue 5b. Restore the context using the head of the Ready Queue

Complete example:

Initial situation:
The CPU sends out an address and the MMU detects the page fault (the page is not in memory.
The MMU sends out and interrupt:
The CPU executes the MMU interrupt handler which will:
Result:

Notice that the current page table pointer has changed !!!

Therefore:

When the page fault handler finishes, another program will be running (just like the case when the current program performs an IO request...).
This program has its own page table and the current page table register is pointing to the page table of the new process !!!
Notice also: the DMA has been started to fetch the missing page (from the previously current process) from disk on behave of the "previously current program".

There is one more loose end to the story:
- How does the stopped program get the CPU back so that it can run again.
We have seen a similar story when we discuss the IO communication.
The solution is of course: use interrupt.
However: we must distinguish the case of a page fault from an "ordinary" disk read (file access) operation
(Because in a page fault the OS must update some page table entries, and in an "ordinary" disk read (file access), the page table does not change.)

When the disk read operation that fetches the missing page for the "former current program" completes, the DMA will sends out an interrupt.

As explained in the Interrupt handling syllabus pages (see: click here), the CPU will suspend the current running program and make an "unforseen" subroutine call to the DMA interrupt handler.

The DMA interrupt handler will execute and detects (from the newly introduced variable in the PCB) that the program that was waiting on the DMA had a page fault.

We need a new (= updated) DMA handler that can distiguish a normal Disk IO from a disk IO caused by a page fault.

Here is the updated DMA interrupt handler:

Updated DMA interrupt handler: =========================== (modified to differentiate between: A. normal disk read B. disk read due to a page fault ------------------------------------------------------------ 0. Acknowledge Interrupt (CPU will receive vector from DMA) and call the DMA interrupt handler ============================================================ 1. Save context from CPU into the PCB at the head of the Ready Queue 2. Remove the PCB from the DMA Queue 3. Insert this PCB at the head of the Ready Queue (This process is the NEW current running process !) Make the page table of this process the current page table by updating the current page table register in MMU ****** (added for paging) 4. If ( PCB.pageFault == TRUE (i.e., program had a page fault) ) { Update page table entries in MMU Specifically, you must: 1. Set the valid bit of the fetched page to VALID 2. Enter the page number for the fetched program page into the page entry 3. If you replaced an existing page, you must also invalid the corresponding page entry (Usually, you replace one of YOUR own pages and does not "steal" a frame from another process) } 5a. Update current page table register of MMU to point to: the page table of the program that at the head of the Ready Queue 5b. Restore the context using the head of the Ready Queue

If you compare the new DMA interrupt handler with the old one on this webpage: click here, the only difference is that when the program was waiting on the DMA because of a page fault, then after the disk IO completes (the page has been read into memory), we must also update the page table to reflect a NEW memory mapping.
That's why I said very early on that the memory mapping used in paging is dynamic.... it changes from time to time.
How the mapping change depends on
- which pages are brought into the memory, and more importantly,
- which pages are removed from the memory !!! (because the memory cannot hold all the pages, and some "older" pages will have to be replaced).

Complete example of the DMA handling:

Initial situation:
The green program had a page fault and started a disk IO operation to read the missing page from disk
When the DMA finishes transfering the program page to memory, the DMA sends out an iterrupt signal:

This will make the CPU run the updated DMA interrupt handler which will:

Move the green program from the DMA queue to the head of the ready queue
Because the PCB.pageFault is true, we will update the page table entry for the missing page
(Now the page table entry will say that program page is in memory !!!)
Load the context of the (new) head of the reqdy queue (= the green program)

Result: the green program is running again

The performance of the paging system depends heavily on how smart you manage the set of pages in the memory - which is gonna be the next topic.