From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <384813965.25550@ustc.edu.cn> Date: Thu, 19 Jul 2007 10:59:27 +0800 From: Fengguang Wu Subject: Re: [patch] fix periodic superblock dirty inode flushing Message-ID: <20070719025927.GA11874@mail.ustc.edu.cn> References: <20070712120519.8a7241dd.akpm@linux-foundation.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: owner-linux-mm@kvack.org Return-Path: To: Ken Chen Cc: Andrew Morton , linux-mm@kvack.org List-ID: On Mon, Jul 16, 2007 at 05:01:31PM -0700, Ken Chen wrote: > On 7/13/07, Ken Chen wrote: > >On 7/12/07, Andrew Morton wrote: > >> Was this tested in combination with check_dirty_inode_list.patch, > >> to make sure that the time-orderedness is being retained? > > > >I think I tested with the debug patch. And just to be sure, I ran the > >test again with the time-order check in place. It passed the test. > > I ran some more tests over the weekend with the debug turned on. There > are a few fall out that the order-ness of sb-s_dirty is corrupted. We > probably should drop this patch until I figure out a real solution to > this. > > One idea is to use rb-tree for sorting and use a in-tree dummy node as > a tree iterator. Do you think that will work better? I will hack on > that. Sorry if I'm not backgrounded. But what's the problem of a list? If we always do the two actions *together*: 1) update inode->dirtied_when 2) requeue inode in the correct place the list will be in order. linux-2.6.22-rc6-mm1/fs/fs-writeback.c obviously obeys this rule. I don't see how can a new data structure make life easier. 1) and 2) should still be safeguarded, isn't it? -- 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