Mulyadi, Please see in line with tag <Raja1>
Mulyadi Santosa <mulyadi.santosa@xxxxxxxxx> wrote:
Mulyadi Santosa <mulyadi.santosa@xxxxxxxxx> wrote:
Hello... :)
> 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 ..
Yes, and I think the place to save the current state (registers and so
on) is task_struct->thread. read below how I can get to this
conclusion...
>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 ..
To get the clearer picture, try to check arch/i386/kernel/entry.S.
First, check out the BUILD_INTERRUPT() macro. It is used to setup the
interrupt handler for all interrupt vector. Notice, there is a jump to
ret_from_intr on every end of interrupt handler.
Let's continue to "ret_from_intr" label. There is a test to decide next
destination:
testl $(VM_MASK | 3), %eax
jz resume_kernel # returning to kernel or vm86-space
Assume we are going back to kernel space, so it jumps to
"resume_kernel". Let's move there...
Notice that "resume_kernel" is sorrounded by #ifdef CONFIG_PREEMPT, so
if you don't enable kernel preemption, it will just become a function
to restore all the registers and other necessary variable.
back to resume_kernel, there is an interesting call, that is
preempt_schedule_irq. When you check the function's implementation, you
will see a call to schedule(). This is where kernel mode preemption
happen :)<Raja1>1. In your previous reply, you said "ret_from_intr() also calls ret_from_sys_call()" .As ret_from_sys_call() will call schedule(), then what is the need for ret_from_intr() to jump to resume_kernel and then preempt_schedule_irq() and then call schedule() ??Am I confused too much :) ?2. Also if ret_from_intr() calls ret_from_sys_call() which in turn will call schedule() if the time slice is over..., then how / why does a non-preemptive kernel wait till it returns to user mode to reschedule ? Because there is a chance of calling schedule() on the return from interrupt handler.., right ? </Raja1>
> the difference here is that the kernel execution can be preempted not
> only by an interrupt .. so what can also preempt the kernel ?
If there is more important task that is ready to run. "More important"
here means the task has higher priority (lesser nice value)
>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 think it is similar to "traditional" context switch, since both "back
to user mode" and "pure kernel mode preemption" call schedule(). There
is a check however to decide whether it is allowed to do kernel
preemption or not (check preempt_schedule_irq() ):
struct thread_info *ti = current_thread_info();
....
BUG_ON(ti->preempt_count || !irqs_disabled());
So as you can see, if preempt_count (a flag to determine whether it is
ok to do kernel preemption, if zero, then you can continue) is zero OR
irq is not disabled), then you can't continue....a kernel panic
actually :)
I hope I give clear picture....as always, somebody please CMIIW...<Raja1> Can you pls explain the above point ? What do you mean by "you can continue" , "you can't continue" etc ? </Raja1>
regards
Mulyadi
Yahoo! Photos
Got holiday prints? See all the ways to get quality prints in your hands ASAP.
