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 :) I hope I give clear picture....as always, somebody please CMIIW... regards Mulyadi -- Kernelnewbies: Help each other learn about the Linux kernel. Archive: http://mail.nl.linux.org/kernelnewbies/ FAQ: http://kernelnewbies.org/faq/
