On Thu, 2004-06-24 at 16:13 +0530, Dhiman, Gaurav wrote: > You are right to great extent. As far as I understand, in preemptive > kernel the timer interrupt plays an important role. On every > timer-interrupt, it checks if the time allotted to the current process > is expired or not, in case it has not been expired yet, it does not > switch the current running task. If it finds that the time allocated to > current process has been expired, then it uses the bottom half > functionality of kernel to make the calls to scheduler at some later > time, when its bottom half handler will be called. Scheduler will save > the context of current running process (does not matter if process is in > user mode or in kernel mode, in both cases it will switch). > > Frankly speaking this is my perception, it might be wrong, if somebody > finds it wrong, please correct it. Sure. A couple corrections: The timer interrupt does the timeslice check as you describe in the same manner, whether or not CONFIG_PREEMPT is enabled. It simply sets the need_resched flag. The actual preemption occurs when the timer interrupt returns (it actually occurs when any interrupt returns). If need_resched is set, the interrupt handler will invoke the scheduler to choose a new task. With !CONFIG_PREEMPT, this can only occur if the interrupt is returning to user-space. With CONFIG_PREEMPT, this can additionally occur when returning to kernel-space if preempt_count==0. Bottom halves are not involved. Robert Love -- Kernelnewbies: Help each other learn about the Linux kernel. Archive: http://mail.nl.linux.org/kernelnewbies/ FAQ: http://kernelnewbies.org/faq/
