Message-ID: <400644884.18765@ustc.edu.cn>
Date: Fri, 18 Jan 2008 16:27:52 +0800
From: Fengguang Wu <wfg@mail.ustc.edu.cn>
To: Michael Rubin <mrubin@google.com>
Cc: Andrew Morton <akpm@osdl.org>, Peter Zijlstra <peterz@infradead.org>,
       linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 00/13] writeback bug fixes and simplifications take 2
References: <400401292.24795@ustc.edu.cn> <532480950801172351p7603e8d0icdc8e2b27c1e0051@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <532480950801172351p7603e8d0icdc8e2b27c1e0051@mail.gmail.com>
User-Agent: Mutt/1.5.12-2006-07-14
Message-Id: <E1JFmZs-0000wa-3r@localhost.localdomain>
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1654
Lines: 39

On Thu, Jan 17, 2008 at 11:51:51PM -0800, Michael Rubin wrote:
> On Jan 15, 2008 4:36 AM, Fengguang Wu <wfg@mail.ustc.edu.cn> wrote:
> > Andrew,
> >
> > This patchset mainly polishes the writeback queuing policies.
> > The main goals are:
> >
> > (1) small files should not be starved by big dirty files
> > (2) sync as fast as possible for not-blocked inodes/pages
> >     - don't leave them out; no congestion_wait() in between them
> > (3) avoid busy iowait for blocked inodes
> >     - retry them in the next go of s_io(maybe at the next wakeup of pdflush)
> >
> > The role of the queues:
> >
> > s_dirty:   park for dirtied_when expiration
> > s_io:      park for io submission
> > s_more_io: for big dirty inodes, they will be retried in this run of pdflush
> >            (it ensures fairness between small/large files)
> > s_more_io_wait: for blocked inodes, they will be picked up in next run of s_io
> 
> Quick question to make sure I get this. Each queue is sorted as such:
> 
> s_dirty - sorted by the dirtied_when field
> s_io - sorted by  no explicit key but by the order we want to process
> in sync_sb_inodes
> s_more_io - held for later they are sorted in the same manner as s_io
> 
> Is that it?

Yes, exactly. s_io and s_more_io can be considered as one list broken
up into two - to provide the cursor for sequential iteration.
And s_more_io_wait is simply a container for blocked inodes.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/