From: gtirtha@gmail.com (Tirtha Ghosh)
To: kernelnewbies@lists.kernelnewbies.org
Subject: spin_lock and scheduler confusion
Date: Fri, 7 Jan 2011 12:32:49 +0530 [thread overview]
Message-ID: <AANLkTi==fW=WUCP9E--UVcyFKg0-i=KBXtxvv4JMVe+T@mail.gmail.com> (raw)
In-Reply-To: <D3F292ADF945FB49B35E96C94C2061B90EE82B58@nsmail.netscout.com>
NMI has greater priority over spinlock, cause this is non maskable and NMI
watchdog can be used for debugging spinlock deadlocks
(CONFIG_DEBUG_SPINLOCK).
So we will hit NMI watchdog even if spinlock is acquired.
On Fri, Jan 7, 2011 at 11:57 AM, Tayade, Nilesh
<Nilesh.Tayade@netscout.com>wrote:
> Hi,
>
> > -----Original Message-----
> > From: kernelnewbies-bounces at kernelnewbies.org [mailto:kernelnewbies-
> > bounces at kernelnewbies.org] On Behalf Of Dave Hylands
> > Sent: Friday, January 07, 2011 10:59 AM
> > To: Viral Mehta
> > Cc: kernelnewbies at kernelnewbies.org
> > Subject: Re: spin_lock and scheduler confusion
> >
> > Hi Viral,
> >
> > On Wed, Jan 5, 2011 at 2:23 PM, Viral Mehta
> > <Viral.Mehta@lntinfotech.com> wrote:
> > >
> > > Hi ,
> > >
> > > I need your help to solve below confusion.
> > >
> [...]
> >
> > Note that you can't sleep while you hold a spinlock. You're not
> > allowed to perform any type of blocking operations. If you're holding
> > the spinlock for any significant length of time, then you're using the
> > wrong design.
> >
> > > spin_lock_irqrestore();
> > > 3. One of the CPU core tries to execute this code and so acquires the
> > lock.
> > > 4. Now, second core is also goes to execute same piece of code and so
> > will
> [...]
> >
> > Not while it's holding the spinlock or waiting for the spinlock.
> >
> > > Ever if timeslice is over for the current task ?
> >
> > The time tick interrupt is what determines when the timeslice is over.
> > Since you have interrupts disabled, the timer interrupt can't happen.
> >
> > > What if scheduler code is running on CPU core-3 and sees that
> > > timeslice for task running on CPU core-2 has expired ?
> >
> > Each core only considers the timeslices for its own core.
> >
> > > I guess timeslice expire case is not as same as preemption. Or may be
> > I am
> > > terribly wrong.
> >
> > You shouldn't be holding a spinlock for periods of time approaching
> > the length of a timeslice. The timer interrupt is what determines the
> > end of a timeslice. No timer interrupt, no end of a timeslice.
> > Preemption is also triggered by the timer interrupt, or by releasing a
> > resource that a higher priority task is waiting for.
>
> May be my understanding is incorrect, but wouldn't we hit the NMI watchdog
> here(assuming we are running on x86/x86_64)?
> We have a system lockup for long time.
> http://lxr.linux.no/#linux+v2.6.37/Documentation/nmi_watchdog.txt
>
> Could someone please clarify?
> >
> > Dave Hylands
>
> --
> Thanks,
> Nilesh
>
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies at kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20110107/0e313cbf/attachment.html
next prev parent reply other threads:[~2011-01-07 7:02 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <D69C90565D53114396BF743585AF5A09122E61E90F@VSHINMSMBX01.vshodc.lntinfotech.com>
2011-01-05 22:23 ` spin_lock and scheduler confusion Viral Mehta
2011-01-07 3:51 ` Alexandre Courbot
2011-01-07 3:56 ` Mulyadi Santosa
2011-01-07 5:28 ` Dave Hylands
2011-01-07 6:27 ` Tayade, Nilesh
2011-01-07 7:02 ` Tirtha Ghosh [this message]
2011-01-07 7:35 ` Rajat Sharma
2011-01-07 7:49 ` nilesh
2011-01-07 8:03 ` anish singh
2011-01-07 9:31 ` nilesh
2011-01-07 13:58 ` Rajat Sharma
2011-01-07 15:49 ` Dave Hylands
2011-01-07 15:51 ` Dave Hylands
2011-01-07 17:46 ` Viral Mehta
2011-01-08 10:58 ` Rajat Sharma
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='AANLkTi==fW=WUCP9E--UVcyFKg0-i=KBXtxvv4JMVe+T@mail.gmail.com' \
--to=gtirtha@gmail.com \
--cc=kernelnewbies@lists.kernelnewbies.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).