From: Andrew Morton <akpm@osdl.org>
To: Ingo Molnar <mingo@elte.hu>
Cc: ccb@acm.org, linux-kernel@vger.kernel.org
Subject: Re: [patch] increase spinlock-debug looping timeouts from 1 sec to 1 min
Date: Mon, 19 Jun 2006 12:55:31 -0700 [thread overview]
Message-ID: <20060619125531.4c72b8cc.akpm@osdl.org> (raw)
In-Reply-To: <20060619113943.GA18321@elte.hu>
On Mon, 19 Jun 2006 13:39:44 +0200
Ingo Molnar <mingo@elte.hu> wrote:
>
> * Andrew Morton <akpm@osdl.org> wrote:
>
> > > The write_trylock + __delay in the loop is not a problem or a bug, as
> > > the trylock will at most _increase_ the delay - and our goal is to not
> > > have a false positive, not to be absolutely accurate about the
> > > measurement here.
> >
> > Precisely. We have delays of over a second (but we don't know how
> > much more than a second). Let's say two seconds. The NMI watchdog
> > timeout is, what? Five seconds?
>
> i dont see the problem.
It's taking over a second to acquire a write_lock. A lock which is
unlikely to be held for more than a microsecond anywhere. That's really
bad, isn't it? Being on the edge of an NMI watchdog induced system crash
is bad, too.
> We'll have tried that lock hundreds of thousands
> of times before this happens. The NMI watchdog will only trigger if we
> do this with IRQs disabled.
tree_lock uses write_lock_irq().
> And it's not like the normal
> __write_lock_failed codepath would be any different: for heavily
> contended workloads the overhead is likely in the cacheline bouncing,
> not in the __delay().
Yes, it might also happen with !CONFIG_DEBUG_SPINLOCK. We need to find out
if that's so and if so, why.
> > That's getting too close. The result will be a total system crash.
> > And RH are shipping this.
>
> I dont see a connection. Pretty much the only thing the loop condition
> impacts is the condition under which we print out a 'i think we
> deadlocked' message.
I'm assuming that the additional delay in the debug code has worsened the
situation.
> Have i missed your point perhaps?
I get that impression ;) If it takes 1-2 seconds to get this lock then it
can take five seconds. a) that's just gross and b) the NMI watchdog will
nuke the box.
Why is it taking so long to get the lock?
Does it happen in non-debug mode?
What do we do about it?
next prev parent reply other threads:[~2006-06-19 19:55 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-06-12 19:53 BUG: write-lock lockup Charles C. Bennett, Jr.
2006-06-17 17:07 ` Andrew Morton
2006-06-19 7:02 ` [patch] increase spinlock-debug looping timeouts from 1 sec to 1 min Ingo Molnar
2006-06-19 7:59 ` Andrew Morton
2006-06-19 8:12 ` Ingo Molnar
2006-06-19 8:21 ` Ingo Molnar
2006-06-19 8:32 ` Andrew Morton
2006-06-19 8:35 ` Ingo Molnar
2006-06-19 9:13 ` Andrew Morton
2006-06-19 11:39 ` Ingo Molnar
2006-06-19 19:55 ` Andrew Morton [this message]
2006-06-20 8:06 ` Arjan van de Ven
2006-06-20 8:40 ` [patch] fix spinlock-debug looping Ingo Molnar
2006-06-20 8:52 ` Andrew Morton
2006-06-20 9:15 ` Ingo Molnar
2006-06-20 9:32 ` Andrew Morton
2006-06-20 9:34 ` Ingo Molnar
2006-06-20 16:02 ` Dave Olson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20060619125531.4c72b8cc.akpm@osdl.org \
--to=akpm@osdl.org \
--cc=ccb@acm.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®