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: Sun, 18 Feb 2007 15:59:16 -0800 [thread overview] Message-ID: <20070218155916.0d3c73a9.akpm@linux-foundation.org> (raw) In-Reply-To: <E1HIvMB-0005Fd-00@dorka.pomaz.szeredi.hu> On Mon, 19 Feb 2007 00:22:11 +0100 Miklos Szeredi <miklos@szeredi.hu> 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?
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: Sun, 18 Feb 2007 15:59:16 -0800 [thread overview] Message-ID: <20070218155916.0d3c73a9.akpm@linux-foundation.org> (raw) In-Reply-To: <E1HIvMB-0005Fd-00@dorka.pomaz.szeredi.hu> On Mon, 19 Feb 2007 00:22:11 +0100 Miklos Szeredi <miklos@szeredi.hu> 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: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2007-02-18 23:59 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 [this message] 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 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=20070218155916.0d3c73a9.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: linkBe 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.