Re: regression in page writeback

[Wu Fengguang]

On Thu, Sep 24, 2009 at 08:10:34PM +0800, Chris Mason wrote:
> On Thu, Sep 24, 2009 at 11:15:08AM +0800, Wu Fengguang wrote:
> 
> [ why do the bdi-writeback work? ]
> 
[snip]
> > > The congestion checks prevent any attempts from the filesystem to write
> > > a whole extent (or a large portion of an extent) at a time.
> > 
> > Since writepage is called one by one for each page, will its
> > interleaveness impact filesystem decisions? Ie. between these two
> > writepage sequences.
> > 
> >         A1, B1, A2, B2, A3, B3, A4, B4
> >         A1, A2, A3, A4, B1, B2, B3, B4
> > 
> > Where each An/Bn stands for one page of file A/B, n is page index.
> 
> For XFS this is the key question.  We're doing streaming writes, so the
> delayed allocation code is responsible for allocating extents, and this
> is triggered from writepage.  Your first example becomes:
> 
>          A1 [allocate extent A1-A50 ], submit A1
> 	 B1 [allocate extent B1-B50 ], submit B1 (seek)
> 	 A2, (seek back to A1's extent)
> 	 B2, (seek back to B1's extent)
> 	 ...
> 
> This is why the XFS graph for pdflush isn't a straight line.   When we
> back off file A and switch to file B, we seek between extents created by
> delalloc.

Does it mean XFS writeback is somehow serialized, so that the elevator
cannot do request merges well?  Hope that's not true..

> Thanks for spending time reading through all of this.  It's a ton of data
> and your improvements are much appreciated!

Thank you :)

Regards,
Fengguang
--
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/