On 2/1/06, Fawad Lateef <fawadlateef@xxxxxxxxx> wrote:
> On 2/1/06, Mukund JB. <mukundjb@xxxxxxxxxxxxxxxxxxxxx> wrote:
> > Dear Fawad,
> >
> > What I can understand from the following description given by you is:
> >
> > The spinlock if implemented on a Uniprocessor non-preemptable kernel
> > will lead to kernel crash.
> > REASON:
> > The second process will be in busy loop not allowing the Scheduler to
> > schedule the task. It will hang.
> >
> > My questions:
> > scheduler_tick() is a called at regular system routine that the kernel
> > periodically calls and marks processes as needing rescheduling. This
> > call occurs in the timer interrupt context.
> >
> > Now, Lets say that the second process (B) called the spinlock_lock() and
> > is waiting for the first process (A) to unlock. In the mean time, it is
> > sure that scheduler_tick()will be invoked in timer interrupt context.
> > This should take care of the rescheduling the task with this new Process
> > B. Then where is the case of system getting hanged completely.
> >
> > Pleas help me get more clarity on this.
> >
>
> AFAIK in kernel without preemption and no SMP the process (kernel
> process) will never be rescheduled until unless it voluntarily call
> schedule or releases CPU. You can see this behaviour by just inserting
> while(1); (infinite loop) with-in your module and your system will
> hang ! (CMIIW)
>
You are right fawad .....
Mukund, actually when we have kernel without preemption and SMP,
preemption is not done while returning from interrupt or exception to
to kernel execution thread.
In this case, when we are in kernel mode and timer interrupt occurs,
kernel execution flow (in this case busy looping on spinlock) will be
interrupted and the interrupted state will be saved on the kernel
stack and interrupt will be serviced. Lets say, interrupt service
routine identifies that the current process need to be rescheduled and
sets the need_resched in current process task_struct. After servicing
the interrupt, when we return back, they is a check to know is we are
returning to user mode or to kernel mode. In case we are returing to
user mode, we do check the need_resched flag and and call the
schedule() function to schedule another process. In case we are
returing to kernel mode (this is our case, as we were interrupted in
kernel mode) and the kernel is compiled with preemption disabled, we
simply restore the interrupted execution context, which is what we
were doing before interrupt occured, so we keep on looping on
spinlock.
But in case the kernel is compiled with preemption enabled and we are
returing to kernel mode, we do the following thress checks:
If we cannot preempt (preempt count not equal to 0)
restore the interrupted context
if we need not to reschedule (need_resched is clear)
restore the interrupted context
if the interrupts were off before we entered the interrupt (dont know
how this condition can be fullfilled, also dont know the idea behind
checking this condition here, anyone can help out here !! )
restore the interrupted context
try to reschedule
So in above flow will can see that we reschedule only if all three
checks are passed, else we simply restore the interrupted contexet
(kernel execution flow) and keep on doing what we were doing before
interrupt occured.
Hope this helps out in clearing your doubt.
-Gaurav
>
> --
> Fawad Lateef
>
> --
> Kernelnewbies: Help each other learn about the Linux kernel.
> Archive: http://mail.nl.linux.org/kernelnewbies/
> FAQ: http://kernelnewbies.org/faq/
>
>
--
Kernelnewbies: Help each other learn about the Linux kernel.
Archive: http://mail.nl.linux.org/kernelnewbies/
FAQ: http://kernelnewbies.org/faq/
