spin_lock and scheduler confusion
From: Tayade, Nilesh <hidden>
Date: 2011-01-07 06:27:28
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 [off-list ref] wrote:quoted
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.quoted
??? spin_lock_irqrestore(); 3. One of the CPU core tries to execute this code and so acquires thelock.quoted
4. Now, second core is also goes to execute same piece of code and sowill
[...]
Not while it's holding the spinlock or waiting for the spinlock.quoted
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.quoted
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.quoted
I guess?timeslice expire case is not as same as preemption. Or may beI amquoted
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