Re: Understanding non-preemptive kernel

Rajaram Suryanarayanan <rajaram_linux@xxxxxxxxx> · Fri, 20 Jan 2006 02:47:53 -0800 (PST)

Please see in line.

"MHD.Tayseer Alquoatli" <idoit.ief@xxxxxxxxx> wrote:  

  On 1/20/06, Rajaram Suryanarayanan <rajaram_linux@xxxxxxxxx> wrote:    Hi,

  I want to to check my understanding about a non-preemptive kernel like 2.4.

  Please let me know if anything is wrong with the below.

  Suppose a process 1 is in kernel mode. Unless it calls schdeule() voluntarily, it should not be interleaved with another kernel path ( except in case of interrupts and exceptions ). If it is interrupted, then it should be
 continued after the interrupt handler is done. 
  What happens in the case of timer interrupt ?

actually it's not interrupted while it's in kernel mode 

  <Raja> Do you mean only timer interrupt here or any interrupt ? Because I have read that process in kernel mode can be interrupted and continues execution back after completing the interrupt handler. <Raja> 

    I understand that once the time slice is over, the timer interrupt happens and the interrupt handler calls schedule() to schedule another process. But what happens in this case ? the handler does not call schedule() , and enables the current process to continue till it voluntarily relinqueshes the CPU ?

each processes is allowed to
 execute for many ticks .. and the counter field of the process descriptor specifies how many ticks the process is allowed to take from the CPU time
this counter field is updated on each tick .. i.e the counter of the currently running process is decremented each tick, and when the counter reach zero another flag from the current running process will be set which is "need_resced"

  <Raja> Who do this decrementing of the counter and setting the flag etc ? Is it the timer interrupt handler which runs on each tick ? <Raja>
if (current->pid) {
    --current->counter;
    if (current->counter <= 0) {
        current->counter = 0;
        current->need_resched =
 1;
    }
} 

  so it's not interrupted while it's in the kernel mode but it's marked for being scheduled later..
once the process has finished what it was doing in the kernel "a syscall",  it'll call "ret_from_syscall" before it get back to user land
simply the "current->need_resched" is being checked in "ret_from_syscall" .. if it was set then schedule is called .. else it returns to user land to continue executing

  <Raja> I believe above description holds good for only non preemptive kernels. ? How does rescheduling happen in a preemptive kernel ? <Raja>

hope this helps
MHD.Tayseer

    Thanks,
  Rajaram.   

  Yahoo! Autos. Looking for a sweet ride? Get pricing, reviews, & more on new and used cars.   

What are the most popular cars?  Find out at Yahoo! Autos