Thanks for corrections. It makes sense, that when CONFIG_PREEMPT is on it should invoke scheduler if we are returning back to either user or kernel mode. I have one doubt, as you said that timer interrupt sets the need_resched if the time allocated has expired and while returning from any interrupt the the scheduler will be called if need_resched is set. My question is, will the scheduler be invoked by any other interrupts, other than timer interrupt? I think after setting the need_resched when timer interrupt will be returning it will clear the need_resched and will call the scheduler, so all other interrupts occurring after that need not to worry about need_resched and should not check it, as scheduler has already been called by timer interrupt. Why are we checking the need_resched on return of every interrupt as in all cases it will only be handled by timer interrupt? Regards, Gaurav Dhiman -----Original Message----- From: Robert Love [mailto:rml@ximian.com] Sent: Friday, June 25, 2004 12:28 AM To: Dhiman, Gaurav Cc: amith; KERNEL Subject: RE: Premptive vs non-premptive kernel. 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/
