MHD.Tayseer Alquoatli wrote:
On 1/21/06, *Mulyadi Santosa* <mulyadi.santosa@xxxxxxxxx
<mailto: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 :)
> 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 ?
Basically, it's the number of locks held, IIRC. It's only OK to preemt if
nothing holds a lock (and therefore all shared data structures are
consistent).
Cheers,
-- JK
--
Kernelnewbies: Help each other learn about the Linux kernel.
Archive: http://mail.nl.linux.org/kernelnewbies/
FAQ: http://kernelnewbies.org/faq/
