On 1/20/06, Rajaram Suryanarayanan <rajaram_linux@xxxxxxxxx> wrote:
actually it's not interrupted while it's in kernel mode
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"
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
hope this helps
MHD.Tayseer
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
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"
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
hope this helps
MHD.Tayseer
Thanks,Rajaram.
Yahoo! Autos. Looking for a sweet ride? Get pricing, reviews, & more on new and used cars.
