Re: [patch] Converting writeback linked lists to a tree based data structure

!MAILaRCHIVE_VOTE_RePLACE
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]
To: Michael Rubin <mrubin@...>
Cc: <a.p.zijlstra@...>, <akpm@...>, <linux-kernel@...>, <linux-mm@...>
Date: Thursday, January 17, 2008 - 5:41 am

On Tue, Jan 15, 2008 at 12:09:21AM -0800, Michael Rubin wrote:

The main benefit of rbtree is possibly better support of future policies.
Can you demonstrate an example?

(grumble:
Apart from the benefit of flexibility, I don't think it makes things
simpler, nor does the introduction of rbtree automatically fixes bugs.
Bugs can only be avoided by good understanding of all possible cases.)

The most tricky writeback issues could be starvation prevention
between
        - small/large files
        - new/old files
        - superblocks
Some kind of limit should be applied for each. They used to be:
        - requeue to s_more_io whenever MAX_WRITEBACK_PAGES is reached
          this preempts big files
        - refill s_io iif it is drained
          this prevents promotion of big/old files
        - return from sync_sb_inodes() after one go of s_io
          (todo: don't restart from the first superblock in writeback_inodes())
          this prevents busy superblock from starving others
          and ensures fairness between superblocks
 
Michael, could you sort out and document the new starvation prevention schemes?


Introduce i_flush_gen to help restarting from the last inode?
Well, it's not as simple as list_heads.


What do you mean by fairness? Why cannot I_WRITEBACK_NEVER be in a
decoupled standalone patch?



More details about the fixings, please?

--
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]

Messages in current thread:
Re: [patch] Converting writeback linked lists to a tree base..., Fengguang Wu, (Thu Jan 17, 5:41 am)