Need explanation on page fault handling.

Question

Suppose a process is suspended due a page fault(page is being written back to disk or required page is being read from disk). Now after the page IO is completed, the process becomes runnable or resumes execution ? Also will the scenario be different ,if the process itself requested for some IO(read , write , etc) ?

If it just becomes runnable, and if it is of low priority, isn't it possible that by the time it resumes execution the page for which it had faulted has again swapped back to disk ?

Answer 1

It just becomes "runnable". 

Problem with low priority- I don't know how this is actually done, but after swapping in, the priority of the process can be temporarily made quite high. 

"isn't it possible that by the time it resumes execution the page for which it had faulted has again swapped back to disk"

This is the reason for thrashing rt? 

Comments

Indeed sir, it must be thrashing. You are always right.

But I have a little doubt regarding the runnable thing.I also believe that the process becomes runnable after it's IO completes but the book "Modern operating systems" by Tannenbaum says something different. On page 227 under Page Fault Handling following steps are mentioned. Please have a look and clear my doubt. Doesn't points 8,9,10 indicate that process resumes after page IO ?

We are finally in a position to describe in detail what happens on a page fault.

The sequence of events is as follows:

1.   The hardware traps to the kernel, saving the program counter on the  stack.   On most  machines,  some  information  about  the  state  of the  current instruction is saved in special CPU registers.                                 

2.   An assembly code routine is started to save the general registers and  other  volatile  information,  to  keep  the  operating  system  from  destroying it. This routine calls the operating system as a procedure.              

3.   The operating  system  discovers  that- a  page  fault has  occurred,  and tries to discover which  virtual page is needed.  Often one of the hard ware registers contains this information.  If not,  the operating  system  must retrieve the program counter, fetch the instruction, and parse it in software to figure out what it was doing when the fault hit.                    

 4.  Once  the virtual  address  that caused  the fault  is known,  the system  checks  to  see  if  this  address  is  valid  and  the  protection  consistent  with the  access.   If not,  the process is  sent a signal  or killed.   If the  address  is  valid  and  no  protection  fault  has  occurred,  the  system  checks to see if a page frame is free.   If no frames are  free,  the page  replacement algorithm is run to select a victim.                                       

 5.  If the page frame  selected  is  dirty, the  page  is  scheduled for transfer  to the disk, and a context switch takes place, suspending the faulting  process  and  letting  another one run  until  the  disk  transfer has  completed.   In any event,  the frame  is marked as busy to prevent it from  being used for another purpose.                                                                                                                                      

6.  As  soon as  the page  frame is clean  (either immediately  or after it is written  to  disk),  the  operating  system  looks  up  the  disk  address  where  the needed page  is,  and  schedules  a disk  operation  to bring it  in.  While  the  page  is  being  loaded,   the  faulting  process  is  still  suspended and another user process is run, if one is available.                                                              

7.   When the disk interrupt indicates  that the page has  arrived,  the page  tables  are  updated  to reflect its  position,  and  the frame  is marked  as being in normal state.

8.   The faulting instruction is backed up to the state it had when it began  and the program counter is reset to point to that instruction.

9.   The  faulting process  is  scheduled,  and  the  operating  system returns  to the (assembly language) routine that called it.

 10.   This routine reloads  the registers  and  other state information and re turns to user space to continue execution, as if no fault had occurred.

---

Nopes. They say the steps the faulting process goes through- in between these steps other processes might be executing. So, there is no guarantee that steps 8-9-10 are done immediately one after the other.