Messages in this thread | | | Date | Fri, 25 Sep 2009 11:26:11 +0800 | From | Wu Fengguang <> | Subject | Re: regression in page writeback |
| |
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
| |