Re: [patch] fix spinlock-debug looping

[Andrew Morton]

On Tue, 20 Jun 2006 11:15:05 +0200
Ingo Molnar <mingo@xxxxxxx> wrote:

> * Andrew Morton <akpm@xxxxxxxx> wrote:
> 
> > On Tue, 20 Jun 2006 10:40:01 +0200
> > Ingo Molnar <mingo@xxxxxxx> 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 <olson@xxxxxxxxxxxx>'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
ccb@xxxxxxx (?) 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/