Messages in this thread | | | Date | Tue, 20 Jun 2006 02:32:16 -0700 | From | Andrew Morton <> | Subject | Re: [patch] fix spinlock-debug looping |
| |
On Tue, 20 Jun 2006 11:15:05 +0200 Ingo Molnar <mingo@elte.hu> wrote:
> * Andrew Morton <akpm@osdl.org> wrote: > > > On Tue, 20 Jun 2006 10:40:01 +0200 > > Ingo Molnar <mingo@elte.hu> 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@unixfolk.com>'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@acm.org (?) 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |