On 1/20/06, Mulyadi Santosa <mulyadi.santosa@xxxxxxxxx> wrote:
thanks for the answer .. but this way the kernel must remember where it was preempted so it can get back to execute what it was doing before the preemption took place .. this is similar to an interrupt in a non-preemptable kernel that stops the kernel execution .. do the interrupt handler, then get back to it's work ..
the difference here is that the kernel execution can be preempted not only by an interrupt .. so what can also preempt the kernel ? and how the scheduler remembers the (n) place where the kernel has been preempted (n) times ? is it like the traditional context switch or there is any difference?
i hope the question is clear
MHD.Tayseer
Hi.....
> yes you are right .. i mean it's not going to be interrupted cause
> it's time quantum has finished .. but interrupts coming from hardware
> (for example) will interrupt the execution for sure and continue
> execution after the completion of the interrupt handler as you've
> noted
Sometimes the word "interrupted" brings confusion when you talk about
interrupts :) Interrupt (be it a software interrupt or hardware
interrupt) interrupts current CPU execution path and switch to
interrupt handler. After it is finished, CPU jumps back to the last
interrupted code path by using information saved on kernel mode stack
(which is EIP, instruction pointer)
But the interrupt itself doesn't change the current running process,
it's just the process's code that is interleaved by interrupt handler.
> > <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>
> yes
To be precise, by the bottom half of the interrupt timer
> > 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
A bit out of context from original question. Please notice that even the
task is in user mode when the time slice is over, it will still be
scheduled out. Why? Simply because ret_from_syscall's code segment is
also called by ret_from_intr. So, the above rule is still valid even
the process is in user mode.
> > <Raja> I believe above description holds good for only non
> > preemptive kernels. ? How does rescheduling happen in a preemptive
> > kernel ? <Raja>
basically, in preemptive kernel, there are more preemption point. The
addition is, scheduling can happen even the process comes back to
kernel mode, while in non preemptive kernel, scheduling only happens
when the process wants to return to user mode only.
thanks for the answer .. but this way the kernel must remember where it was preempted so it can get back to execute what it was doing before the preemption took place .. this is similar to an interrupt in a non-preemptable kernel that stops the kernel execution .. do the interrupt handler, then get back to it's work ..
the difference here is that the kernel execution can be preempted not only by an interrupt .. so what can also preempt the kernel ? and how the scheduler remembers the (n) place where the kernel has been preempted (n) times ? is it like the traditional context switch or there is any difference?
i hope the question is clear
MHD.Tayseer
Hope this helps
regards
Mulyadi
