public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: Matthias Hensler <matthias@wspse.de>
Cc: Chuck Ebbert <cebbert@redhat.com>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	richard kennedy <richard@rsk.demon.co.uk>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>
Subject: Re: Processes spinning forever, apparently in lock_timer_base()?
Date: Thu, 9 Aug 2007 09:55:34 -0700	[thread overview]
Message-ID: <20070809095534.25ae1c42.akpm@linux-foundation.org> (raw)
In-Reply-To: <20070809095943.GA7763@kobayashi-maru.wspse.de>

On Thu, 9 Aug 2007 11:59:43 +0200 Matthias Hensler <matthias@wspse.de> wrote:

> On Sat, Aug 04, 2007 at 10:44:26AM +0200, Matthias Hensler wrote:
> > On Fri, Aug 03, 2007 at 11:34:07AM -0700, Andrew Morton wrote:
> > [...]
> > I am also willing to try the patch posted by Richard.
> 
> I want to give some update here:
> 
> 1. We finally hit the problem on a third system, with a total different
>    setup and hardware. However, again high I/O load caused the problem
>    and the affected filesystems were mounted with noatime.
> 
> 2. I installed a recompiled kernel with just the two line patch from
>    Richard Kennedy (http://lkml.org/lkml/2007/8/2/89). That system has 5
>    days uptime now and counting. I believe the patch fixed the problem.
>    However, I will continue running "vmstat 1" and the endless loop of
>    "cat /proc/meminfo", just in case I am wrong.
> 

Did we ever see the /proc/meminfo and /proc/vmstat output during the stall?

If Richard's patch has indeed fixed it then this confirms that we're seeing
contention over the dirty-memory limits.  Richard's patch isn't really the
right one because it allows unlimited dirty-memory windup in some situations
(large number of disks with small writes, or when we perform queue congestion
avoidance).

As you're seeing this happening when multiple disks are being written to it is
possible that the per-device-dirty-threshold patches which recently went into
-mm (and which appear to have a bug) will fix it.

But I worry that the stall appears to persist *forever*.  That would indicate
that we have a dirty-memory accounting leak, or that for some reason the
system has decided to stop doing writeback to one or more queues (might be
caused by an error in a lower-level driver's queue congestion state management).

If it is the latter, then it could be that running "sync" will clear the
problem.  Temporarily, at least.  Because sync will ignore the queue congestion
state.

  reply	other threads:[~2007-08-09 16:57 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-08-01 22:39 Processes spinning forever, apparently in lock_timer_base()? Chuck Ebbert
2007-08-02 10:37 ` richard kennedy
2007-08-03 18:34 ` Andrew Morton
2007-08-04  8:44   ` Matthias Hensler
2007-08-09  9:59     ` Matthias Hensler
2007-08-09 16:55       ` Andrew Morton [this message]
2007-08-09 17:37         ` Matthias Hensler
2007-09-20 21:07         ` Chuck Ebbert
2007-09-20 21:29           ` Andrew Morton
2007-09-20 22:04             ` Chuck Ebbert
2007-09-20 22:36               ` Andrew Morton
2007-09-20 22:44                 ` Chuck Ebbert
2007-09-21  8:08                 ` Matthias Hensler
2007-09-21  8:22                   ` Andrew Morton
2007-09-21 10:25                 ` richard kennedy
2007-09-21 10:33                   ` Andrew Morton
2007-09-21 10:47                     ` richard kennedy
2007-09-22 12:08                     ` richard kennedy
2007-09-21  9:39             ` Andy Whitcroft
2007-09-21 15:43               ` Chuck Ebbert
2007-09-21 15:58               ` Hugh Dickins
2007-09-21 16:16                 ` Chuck Ebbert
2007-09-21 18:54                 ` Peter Zijlstra
2007-10-29 18:55                 ` Bruno Wolff III
  -- strict thread matches above, loose matches on Subject: below --
2007-08-03 20:14 Oleg Nesterov

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=20070809095534.25ae1c42.akpm@linux-foundation.org \
    --to=akpm@linux-foundation.org \
    --cc=a.p.zijlstra@chello.nl \
    --cc=cebbert@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=matthias@wspse.de \
    --cc=richard@rsk.demon.co.uk \
    --cc=tglx@linutronix.de \
    /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