Re: [patch] fix spinlock-debug looping

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, 20 Jun 2006 11:15:05 +0200
Ingo Molnar <[email protected]> wrote:

> * Andrew Morton <[email protected]> wrote:
> 
> > On Tue, 20 Jun 2006 10:40:01 +0200
> > Ingo Molnar <[email protected]> wrote:
> > 
> > > i obviously agree that any such crash is a serious problem, but is 
> > > it caused by the spinlock-debugging code?
> > 
> > Judging from Dave Olson <[email protected]>'s report: no.  He's 
> > getting hit by NMI watchdog expiry on write_lock(tree_lock) in a 
> > !CONFIG_DEBUG_SPINLOCK kernel.
> 
> hm, that means 5 seconds of looping with irqs off?

Yup.

> That's really insane. 

Yup.

> Is there any definitive testcase or testsystem where we could try a 
> simple tree_lock rwlock -> spinlock conversion?

Not that I'm aware of.  I just tried three CPUs doing
fadvise(FADV_WILLNEED, 1GB) with the fourth CPU trying to write the file,
but it didn't lock up as I expected.

> Spinlocks are alot 
> fairer. Or as a simple experiment, s/read_lock/write_lock, as the patch 
> below (against rc6-mm2) does. This is phase #1, if it works out we can 
> switch tree_lock to a spinlock. [write_lock()s are roughly as fair to 
> each other as spinlocks - it's a bit more expensive but not 
> significantly] Builds & boots fine here.

tree_lock was initially an rwlock.  Then we made it a spinlock.  Then we
made it an rwlock.  We change the dang thing so often we should make it a
macro ;)

Let's just make it a spinlock and be done with it.  Hopefully Dave or
[email protected] (?) will be able to test it.  I was planning on doing a patch
tomorrowish.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux