On 1/21/06, Mulyadi Santosa <mulyadi.santosa@xxxxxxxxx> wrote:
thanks for the explanation
about the meaning of "preempt_count" is it as it's name implies ? does it means "how many times the kernel has been preempted" or "how many times this process has been preempted while it was in the kernel" or it has nothing to do with the count and it's just a flag ?
thanks
MHD.Tayseer
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 :)
> 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 :)
thanks for the explanation
about the meaning of "preempt_count" is it as it's name implies ? does it means "how many times the kernel has been preempted" or "how many times this process has been preempted while it was in the kernel" or it has nothing to do with the count and it's just a flag ?
thanks
MHD.Tayseer
I hope I give clear picture....as always, somebody please CMIIW...
regards
Mulyadi
