Re: dirty balancing deadlock
From: Andrew Morton
Date: Sun Feb 18 2007 - 18:59:38 EST
On Mon, 19 Feb 2007 00:22:11 +0100 Miklos Szeredi <miklos@xxxxxxxxxx> 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 from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/