From: Dave Chinner <david@fromorbit.com>
To: Tejun Heo <tj@kernel.org>
Cc: linux-kernel@vger.kernel.org, xfs@oss.sgi.com,
linux-fsdevel@vger.kernel.org
Subject: Re: [2.6.36-rc3] Workqueues, XFS, dependencies and deadlocks
Date: Tue, 7 Sep 2010 23:02:43 +1000 [thread overview]
Message-ID: <20100907130243.GQ705@dastard> (raw)
In-Reply-To: <4C862F8E.7030507@kernel.org>
On Tue, Sep 07, 2010 at 02:26:54PM +0200, Tejun Heo wrote:
> On 09/07/2010 12:35 PM, Tejun Heo wrote:
> > Can you please help me a bit more? Are you saying the following?
> >
> > Work w0 starts execution on wq0. w0 tries locking but fails. Does
> > delay(1) and requeues itself on wq0 hoping another work w1 would be
> > queued on wq0 which will release the lock. The requeueing should make
> > w0 queued and executed after w1, but instead w1 never gets executed
> > while w0 hogs the CPU constantly by re-executing itself. Also, how
> > does delay(1) help with chewing up CPU? Are you talking about
> > avoiding constant lock/unlock ops starving other lockers? In such
> > case, wouldn't cpu_relax() make more sense?
>
> Ooh, almost forgot. There was nr_active underflow bug in workqueue
> code which could lead to malfunctioning max_active regulation and
> problems during queue freezing, so you could be hitting that too. I
> sent out pull request some time ago but hasn't been pulled into
> mainline yet. Can you please pull from the following branch and add
> WQ_HIGHPRI as discussed before and see whether the problem is still
> reproducible?
I'm currently running with the WQ_HIGHPRI flag. I only change one
thing at a time so I can tell what caused the change in behaviour...
> And if the problem is reproducible, can you please
> trigger sysrq thread dump and attach it?
Well, most of the time the system is 100% unresponsive when the
livelock occurs, so I'll be lucky to get anything at all....
> git://git.kernel.org/pub/scm/linux/kernel/git/tj/wq.git for-linus
I'll try that next if the probelm still persists.
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
next prev parent reply other threads:[~2010-09-07 13:02 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-09-07 7:29 [2.6.36-rc3] Workqueues, XFS, dependencies and deadlocks Dave Chinner
2010-09-07 9:04 ` Tejun Heo
2010-09-07 10:01 ` Dave Chinner
2010-09-07 10:35 ` Tejun Heo
2010-09-07 12:26 ` Tejun Heo
2010-09-07 13:02 ` Dave Chinner [this message]
2010-09-08 8:22 ` Dave Chinner
2010-09-08 8:51 ` Tejun Heo
2010-09-08 10:05 ` Dave Chinner
2010-09-08 14:10 ` Tejun Heo
2010-09-07 12:48 ` Dave Chinner
2010-09-07 15:39 ` Tejun Heo
2010-09-08 7:34 ` Dave Chinner
2010-09-08 8:20 ` Tejun Heo
2010-09-08 8:28 ` Dave Chinner
2010-09-08 8:46 ` Tejun Heo
2010-09-08 10:12 ` Dave Chinner
2010-09-08 10:28 ` Tejun Heo
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=20100907130243.GQ705@dastard \
--to=david@fromorbit.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=tj@kernel.org \
--cc=xfs@oss.sgi.com \
/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;
as well as URLs for NNTP newsgroup(s).