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]
