All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: dirty balancing deadlock
Date: Wed, 21 Feb 2007 23:55:32 -0800	[thread overview]
Message-ID: <20070221235532.2361f827.akpm@linux-foundation.org> (raw)
In-Reply-To: <E1HK8aw-0005Lg-00@dorka.pomaz.szeredi.hu>

> On Thu, 22 Feb 2007 08:42:26 +0100 Miklos Szeredi <miklos@szeredi.hu> wrote:
> > > 
> > > Index: linux/mm/page-writeback.c
> > > ===================================================================
> > > --- linux.orig/mm/page-writeback.c	2007-02-19 17:32:41.000000000 +0100
> > > +++ linux/mm/page-writeback.c	2007-02-19 18:05:28.000000000 +0100
> > > @@ -198,6 +198,25 @@ static void balance_dirty_pages(struct a
> > >  			dirty_thresh)
> > >  				break;
> > >  
> > > +		/*
> > > +		 * Acquit this producer if there's little or nothing
> > > +		 * to write back to this particular queue
> > > +		 *
> > > +		 * Without this check a deadlock is possible in the
> > > +		 * following case:
> > > +		 *
> > > +		 * - filesystem A writes data through filesystem B
> > > +		 * - filesystem A has dirty pages over dirty_thresh
> > > +		 * - writeback is started, this triggers a write in B
> > > +		 * - balance_dirty_pages() is called synchronously
> > > +		 * - the write to B blocks
> > > +		 * - the writeback completes, but dirty is still over threshold
> > > +		 * - the blocking write prevents futher writes from happening
> > > +		 */
> > > +		if (atomic_long_read(&bdi->nr_dirty) +
> > > +		    atomic_long_read(&bdi->nr_writeback) < 16)
> > > +			break;
> > > +
> > 
> > The problem seems to that little "- the write to B blocks".
> > 
> > How come it blocks?  I mean, if we cannot retire writes to that filesystem
> > then we're screwed anyway.
> 
> Sorry about the sloppy description.  I mean, it's not the lowlevel
> write that will block, but rather the VFS one
> (generic_file_aio_write).  It will block (or rather loop forever with
> 0.1 second sleeps) in balance_dirty_pages().  That means, that for
> this inode, i_mutex is held and no other writer can continue the work.

"this inode" I assume is the inode against filesystem A?

Why does holding that inode's i_mutex prevent further writeback of pages in A?



WARNING: multiple messages have this Message-ID (diff)
From: Andrew Morton <akpm@linux-foundation.org>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: dirty balancing deadlock
Date: Wed, 21 Feb 2007 23:55:32 -0800	[thread overview]
Message-ID: <20070221235532.2361f827.akpm@linux-foundation.org> (raw)
In-Reply-To: <E1HK8aw-0005Lg-00@dorka.pomaz.szeredi.hu>

> On Thu, 22 Feb 2007 08:42:26 +0100 Miklos Szeredi <miklos@szeredi.hu> wrote:
> > > 
> > > Index: linux/mm/page-writeback.c
> > > ===================================================================
> > > --- linux.orig/mm/page-writeback.c	2007-02-19 17:32:41.000000000 +0100
> > > +++ linux/mm/page-writeback.c	2007-02-19 18:05:28.000000000 +0100
> > > @@ -198,6 +198,25 @@ static void balance_dirty_pages(struct a
> > >  			dirty_thresh)
> > >  				break;
> > >  
> > > +		/*
> > > +		 * Acquit this producer if there's little or nothing
> > > +		 * to write back to this particular queue
> > > +		 *
> > > +		 * Without this check a deadlock is possible in the
> > > +		 * following case:
> > > +		 *
> > > +		 * - filesystem A writes data through filesystem B
> > > +		 * - filesystem A has dirty pages over dirty_thresh
> > > +		 * - writeback is started, this triggers a write in B
> > > +		 * - balance_dirty_pages() is called synchronously
> > > +		 * - the write to B blocks
> > > +		 * - the writeback completes, but dirty is still over threshold
> > > +		 * - the blocking write prevents futher writes from happening
> > > +		 */
> > > +		if (atomic_long_read(&bdi->nr_dirty) +
> > > +		    atomic_long_read(&bdi->nr_writeback) < 16)
> > > +			break;
> > > +
> > 
> > The problem seems to that little "- the write to B blocks".
> > 
> > How come it blocks?  I mean, if we cannot retire writes to that filesystem
> > then we're screwed anyway.
> 
> Sorry about the sloppy description.  I mean, it's not the lowlevel
> write that will block, but rather the VFS one
> (generic_file_aio_write).  It will block (or rather loop forever with
> 0.1 second sleeps) in balance_dirty_pages().  That means, that for
> this inode, i_mutex is held and no other writer can continue the work.

"this inode" I assume is the inode against filesystem A?

Why does holding that inode's i_mutex prevent further writeback of pages in A?


--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2007-02-22  7:55 UTC|newest]

Thread overview: 52+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-02-18 18:28 dirty balancing deadlock Miklos Szeredi
2007-02-18 18:28 ` Miklos Szeredi
2007-02-18 20:53 ` Andrew Morton
2007-02-18 20:53   ` Andrew Morton
2007-02-18 21:25   ` Rik van Riel
2007-02-18 21:25     ` Rik van Riel
2007-02-18 22:54     ` Miklos Szeredi
2007-02-18 22:54       ` Miklos Szeredi
2007-02-18 22:50   ` Miklos Szeredi
2007-02-18 22:50     ` Miklos Szeredi
2007-02-18 22:59     ` Andrew Morton
2007-02-18 22:59       ` Andrew Morton
2007-02-18 23:22       ` Miklos Szeredi
2007-02-18 23:22         ` Miklos Szeredi
2007-02-18 23:59         ` Andrew Morton
2007-02-18 23:59           ` Andrew Morton
2007-02-19  0:25           ` Miklos Szeredi
2007-02-19  0:25             ` Miklos Szeredi
2007-02-19  0:30             ` Miklos Szeredi
2007-02-19  0:30               ` Miklos Szeredi
2007-02-19  0:45             ` Miklos Szeredi
2007-02-19  0:45               ` Miklos Szeredi
2007-02-19  0:45             ` Chris Mason
2007-02-19  0:45               ` Chris Mason
2007-02-19  0:54               ` Miklos Szeredi
2007-02-19  0:54                 ` Miklos Szeredi
2007-02-19  1:01                 ` Chris Mason
2007-02-19  1:01                   ` Chris Mason
2007-02-19  1:14                   ` Miklos Szeredi
2007-02-19  1:14                     ` Miklos Szeredi
2007-02-20  0:16                     ` Chris Mason
2007-02-20  0:16                       ` Chris Mason
2007-02-20  8:53                       ` Miklos Szeredi
2007-02-20  8:53                         ` Miklos Szeredi
2007-02-19 17:11           ` Miklos Szeredi
2007-02-19 17:11             ` Miklos Szeredi
2007-02-19 23:12             ` Miklos Szeredi
2007-02-19 23:12               ` Miklos Szeredi
2007-02-20  0:13             ` Chris Mason
2007-02-20  0:13               ` Chris Mason
2007-02-20  8:47               ` Miklos Szeredi
2007-02-20  8:47                 ` Miklos Szeredi
2007-02-20 11:30                 ` Chris Mason
2007-02-20 11:30                   ` Chris Mason
2007-02-21 21:36             ` Andrew Morton
2007-02-21 21:36               ` Andrew Morton
2007-02-22  7:42               ` Miklos Szeredi
2007-02-22  7:42                 ` Miklos Szeredi
2007-02-22  7:55                 ` Andrew Morton [this message]
2007-02-22  7:55                   ` Andrew Morton
2007-02-22  8:02                   ` Miklos Szeredi
2007-02-22  8:02                     ` Miklos Szeredi

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=20070221235532.2361f827.akpm@linux-foundation.org \
    --to=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=miklos@szeredi.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.