From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752516AbXBRX7X (ORCPT ); Sun, 18 Feb 2007 18:59:23 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752527AbXBRX7X (ORCPT ); Sun, 18 Feb 2007 18:59:23 -0500 Received: from smtp.osdl.org ([65.172.181.24]:33767 "EHLO smtp.osdl.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752516AbXBRX7W (ORCPT ); Sun, 18 Feb 2007 18:59:22 -0500 Date: Sun, 18 Feb 2007 15:59:16 -0800 From: Andrew Morton To: Miklos Szeredi Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: dirty balancing deadlock Message-Id: <20070218155916.0d3c73a9.akpm@linux-foundation.org> In-Reply-To: References: <20070218125307.4103c04a.akpm@linux-foundation.org> <20070218145929.547c21c7.akpm@linux-foundation.org> X-Mailer: Sylpheed version 2.2.7 (GTK+ 2.8.17; x86_64-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 19 Feb 2007 00:22:11 +0100 Miklos Szeredi wrote: > > If so, writes to B will decrease the dirty memory threshold. > > Yes, but not by enough. Say A dirties a 1100 pages, limit is 1000. > Some pages queued for writeback (doesn't matter how much). B writes > back 1, 1099 dirty remain in A, zero in B. balance_dirty_pages() for > B doesn't know that there's nothing more to write back for B, it's > just waiting there for those 1099, which'll never get written. hm, OK, arguable. I guess something like this.. --- a/fs/fs-writeback.c~a +++ a/fs/fs-writeback.c @@ -356,7 +356,7 @@ int generic_sync_sb_inodes(struct super_ continue; /* Skip a congested blockdev */ } - if (wbc->bdi && bdi != wbc->bdi) { + if (wbc->bdi && bdi != wbc->bdi && bdi_write_congested(bdi)) { if (!sb_is_blkdev_sb(sb)) break; /* fs has the wrong queue */ list_move(&inode->i_list, &sb->s_dirty); _ but where's pdflush? It should be busily transferring dirtiness from A to B. > > The writeout code _should_ just sit there transferring dirtyiness from A to > > B and cleaning pages via B, looping around, alternating between both. > > > > What does sysrq-t say? > > This is the fuse daemon thread that got stuck. Where's pdflsuh? From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Sun, 18 Feb 2007 15:59:16 -0800 From: Andrew Morton Subject: Re: dirty balancing deadlock Message-Id: <20070218155916.0d3c73a9.akpm@linux-foundation.org> In-Reply-To: References: <20070218125307.4103c04a.akpm@linux-foundation.org> <20070218145929.547c21c7.akpm@linux-foundation.org> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org Return-Path: To: Miklos Szeredi Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org List-ID: On Mon, 19 Feb 2007 00:22:11 +0100 Miklos Szeredi wrote: > > If so, writes to B will decrease the dirty memory threshold. > > Yes, but not by enough. Say A dirties a 1100 pages, limit is 1000. > Some pages queued for writeback (doesn't matter how much). B writes > back 1, 1099 dirty remain in A, zero in B. balance_dirty_pages() for > B doesn't know that there's nothing more to write back for B, it's > just waiting there for those 1099, which'll never get written. hm, OK, arguable. I guess something like this.. --- a/fs/fs-writeback.c~a +++ a/fs/fs-writeback.c @@ -356,7 +356,7 @@ int generic_sync_sb_inodes(struct super_ continue; /* Skip a congested blockdev */ } - if (wbc->bdi && bdi != wbc->bdi) { + if (wbc->bdi && bdi != wbc->bdi && bdi_write_congested(bdi)) { if (!sb_is_blkdev_sb(sb)) break; /* fs has the wrong queue */ list_move(&inode->i_list, &sb->s_dirty); _ but where's pdflush? It should be busily transferring dirtiness from A to B. > > The writeout code _should_ just sit there transferring dirtyiness from A to > > B and cleaning pages via B, looping around, alternating between both. > > > > What does sysrq-t say? > > This is the fuse daemon thread that got stuck. Where's pdflsuh? -- 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: email@kvack.org