As I remember timer interrupt as well is an NMI so, it is possible (although not advised) to call schedule function while holding spinlock on same core.<br><br>spin_lock_irqsave();<br>schedule();<br>spin_lock_irqrestore();<br>
<br>however if you have debugging options turned on like CONFIG_DEBUG_SPINLOCK, you may likely get kernel warning for 'scheduling in atomic context'.<br><br>Then what can happen if this core is allowed to switched to new process? Consider the case where new process as well tries to aquire same spin_lock() which new process can not aquire and start spinning for the lock for ever :). Likewise, other cores will also get locked down.<br>
<br>However stil you can detect softlockup through NMI watchdog.<br><br>Rajat<br><br><div class="gmail_quote">On Fri, Jan 7, 2011 at 12:32 PM, Tirtha Ghosh <span dir="ltr"><<a href="mailto:gtirtha@gmail.com">gtirtha@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">NMI has greater priority over spinlock, cause this is non maskable and NMI watchdog can be used for debugging spinlock deadlocks (CONFIG_DEBUG_SPINLOCK).<br>
<br>So we will hit NMI watchdog even if spinlock is acquired. <br><div><div></div><div class="h5">
<br><br><br><div class="gmail_quote">On Fri, Jan 7, 2011 at 11:57 AM, Tayade, Nilesh <span dir="ltr"><<a href="mailto:Nilesh.Tayade@netscout.com" target="_blank">Nilesh.Tayade@netscout.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Hi,<br>
<br>
> -----Original Message-----<br>
> From: <a href="mailto:kernelnewbies-bounces@kernelnewbies.org" target="_blank">kernelnewbies-bounces@kernelnewbies.org</a> [mailto:<a href="mailto:kernelnewbies-" target="_blank">kernelnewbies-</a><br>
> <a href="mailto:bounces@kernelnewbies.org" target="_blank">bounces@kernelnewbies.org</a>] On Behalf Of Dave Hylands<br>
> Sent: Friday, January 07, 2011 10:59 AM<br>
> To: Viral Mehta<br>
> Cc: <a href="mailto:kernelnewbies@kernelnewbies.org" target="_blank">kernelnewbies@kernelnewbies.org</a><br>
> Subject: Re: spin_lock and scheduler confusion<br>
><br>
> Hi Viral,<br>
><br>
> On Wed, Jan 5, 2011 at 2:23 PM, Viral Mehta<br>
> <<a href="mailto:Viral.Mehta@lntinfotech.com" target="_blank">Viral.Mehta@lntinfotech.com</a>> wrote:<br>
> ><br>
> > Hi ,<br>
> ><br>
> > I need your help to solve below confusion.<br>
> ><br>
[...]<br>
><br>
> Note that you can't sleep while you hold a spinlock. You're not<br>
> allowed to perform any type of blocking operations. If you're holding<br>
> the spinlock for any significant length of time, then you're using the<br>
> wrong design.<br>
><br>
> > spin_lock_irqrestore();<br>
> > 3. One of the CPU core tries to execute this code and so acquires the<br>
> lock.<br>
> > 4. Now, second core is also goes to execute same piece of code and so<br>
> will<br>
[...]<br>
><br>
> Not while it's holding the spinlock or waiting for the spinlock.<br>
><br>
> > Ever if timeslice is over for the current task ?<br>
><br>
> The time tick interrupt is what determines when the timeslice is over.<br>
> Since you have interrupts disabled, the timer interrupt can't happen.<br>
><br>
> > What if scheduler code is running on CPU core-3 and sees that<br>
> > timeslice for task running on CPU core-2 has expired ?<br>
><br>
> Each core only considers the timeslices for its own core.<br>
><br>
> > I guess timeslice expire case is not as same as preemption. Or may be<br>
> I am<br>
> > terribly wrong.<br>
><br>
> You shouldn't be holding a spinlock for periods of time approaching<br>
> the length of a timeslice. The timer interrupt is what determines the<br>
> end of a timeslice. No timer interrupt, no end of a timeslice.<br>
> Preemption is also triggered by the timer interrupt, or by releasing a<br>
> resource that a higher priority task is waiting for.<br>
<br>
May be my understanding is incorrect, but wouldn't we hit the NMI watchdog here(assuming we are running on x86/x86_64)?<br>
We have a system lockup for long time.<br>
<a href="http://lxr.linux.no/#linux+v2.6.37/Documentation/nmi_watchdog.txt" target="_blank">http://lxr.linux.no/#linux+v2.6.37/Documentation/nmi_watchdog.txt</a><br>
<br>
Could someone please clarify?<br>
><br>
> Dave Hylands<br>
<font color="#888888"><br>
--<br>
Thanks,<br>
Nilesh<br>
<br>
_______________________________________________<br>
Kernelnewbies mailing list<br>
<a href="mailto:Kernelnewbies@kernelnewbies.org" target="_blank">Kernelnewbies@kernelnewbies.org</a><br>
<a href="http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies" target="_blank">http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies</a><br>
</font></blockquote></div><br>
</div></div><br>_______________________________________________<br>
Kernelnewbies mailing list<br>
<a href="mailto:Kernelnewbies@kernelnewbies.org">Kernelnewbies@kernelnewbies.org</a><br>
<a href="http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies" target="_blank">http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies</a><br>
<br></blockquote></div><br>