writeback: write_cache_pages doesn't terminate at nr_to_write <= 0
Subsystems (3)
PATCH 1/1 writeback: write_cache_pages doesn't terminate at nr_to_write <= 0
From: Dave Chinner <[email protected]>
I noticed XFS writeback in 2.6.36-rc1 was much slower than it should have been. Enabling writeback tracing showed:
flush-253:16-8516 [007] 1342952.351608: wbc_writepage: bdi 253:16: towrt=1024 skip=0 mode=0 kupd=0 bgrd=1 reclm=0 cyclic=1 more=0 older=0x0 start=0x0 end=0x0
flush-253:16-8516 [007] 1342952.351654: wbc_writepage: bdi 253:16: towrt=1023 skip=0 mode=0 kupd=0 bgrd=1 reclm=0 cyclic=1 more=0 older=0x0 start=0x0 end=0x0
flush-253:16-8516 [000] 1342952.369520: wbc_writepage: bdi 253:16: towrt=0 skip=0 mode=0 kupd=0 bgrd=1 reclm=0 cyclic=1 more=0 older=0x0 start=0x0 end=0x0
flush-253:16-8516 [000] 1342952.369542: wbc_writepage: bdi 253:16: towrt=-1 skip=0 mode=0 kupd=0 bgrd=1 reclm=0 cyclic=1 more=0 older=0x0 start=0x0 end=0x0
flush-253:16-8516 [000] 1342952.369549: wbc_writepage: bdi 253:16: towrt=-2 skip=0 mode=0 kupd=0 bgrd=1 reclm=0 cyclic=1 more=0 older=0x0 start=0x0 end=0x0Writeback is not terminating in background writeback if ->writepage is returning with wbc->nr_to_write == 0, resulting in sub-optimal single page writeback on XFS.
Fix the write_cache_pages loop to terminate correctly when this situation occurs and so prevent this sub-optimal background writeback pattern. This improves sustained sequential buffered write performance from around 250MB/s to 750MB/s for a 100GB file on an XFS filesystem on my 8p test VM.
--- mm/page-writeback.c | 26 ++++++++++---------------- 1 files changed, 10 insertions(+), 16 deletions(-)
mm/page-writeback.c +10 -16
@@ -984,22 +984,16 @@ continue_unlock: } } -if (wbc->nr_to_write >0 ) { -if (--wbc->nr_to_write ==0 && - wbc->sync_mode ==WB_SYNC_NONE ) { -/* -* We stop writing back only if we are -* not doing integrity sync. In case of -* integrity sync we have to keep going -* because someone may be concurrently -* dirtying pages, and we might have -* synced a lot of newly appeared dirty -* pages, but have not synced all of the -* old dirty pages. -*/ - done =1 ; -break ; - } +/* +* We stop writing back only if we are not doing +* integrity sync. In case of integrity sync we have to +* keep going until we have written all the pages +* we tagged for writeback prior to entering this loop. +*/ +if (--wbc->nr_to_write <=0 && + wbc->sync_mode ==WB_SYNC_NONE ) { + done =1 ; +break ; } }pagevec_release (&pvec);
Signature · 6 lines
1.7.1 _______________________________________________ xfs mailing list [email protected] http://oss.sgi.com/mailman/listinfo/xfs
Quoted 11 lines · Dave Chinner
From: Dave Chinner <[email protected]>
I noticed XFS writeback in 2.6.36-rc1 was much slower than it should have been. Enabling writeback tracing showed:
flush-253:16-8516 [007] 1342952.351608: wbc_writepage: bdi 253:16: towrt=1024 skip=0 mode=0 kupd=0 bgrd=1 reclm=0 cyclic=1 more=0 older=0x0 start=0x0 end=0x0 flush-253:16-8516 [007] 1342952.351654: wbc_writepage: bdi 253:16: towrt=1023 skip=0 mode=0 kupd=0 bgrd=1 reclm=0 cyclic=1 more=0 older=0x0 start=0x0 end=0x0 flush-253:16-8516 [000] 1342952.369520: wbc_writepage: bdi 253:16: towrt=0 skip=0 mode=0 kupd=0 bgrd=1 reclm=0 cyclic=1 more=0 older=0x0 start=0x0 end=0x0 flush-253:16-8516 [000] 1342952.369542: wbc_writepage: bdi 253:16: towrt=-1 skip=0 mode=0 kupd=0 bgrd=1 reclm=0 cyclic=1 more=0 older=0x0 start=0x0 end=0x0 flush-253:16-8516 [000] 1342952.369549: wbc_writepage: bdi 253:16: towrt=-2 skip=0 mode=0 kupd=0 bgrd=1 reclm=0 cyclic=1 more=0 older=0x0 start=0x0 end=0x0
Quoted 3 lines
Writeback is not terminating in background writeback if ->writepage is returning with
wbc->nr_to_write== 0, resulting in sub-optimal single page writeback on XFS.
The new code looks more simple, and more robust in case ->writepage modifies wbc->nr_to_write (as in xfs_vm_writepage).
Thanks,
Fengguang
Quoted 55 lines
Fix the
write_cache_pagesloop to terminate correctly when this situation occurs and so prevent this sub-optimal background writeback pattern. This improves sustained sequential buffered write performance from around 250MB/s to 750MB/s for a 100GB file on an XFS filesystem on my 8p test VM.Signed-off-by Dave Chinner <[email protected]>--- mm/page-writeback.c | 26 ++++++++++---------------- 1 files changed, 10 insertions(+), 16 deletions(-)mm/page-writeback.c +10
-16@@ -984,22 +984,16 @@ continue_unlock: } } -if (wbc->nr_to_write >0 ) { -if (--wbc->nr_to_write ==0 && - wbc->sync_mode ==WB_SYNC_NONE ) { -/* -* We stop writing back only if we are -* not doing integrity sync. In case of -* integrity sync we have to keep going -* because someone may be concurrently -* dirtying pages, and we might have -* synced a lot of newly appeared dirty -* pages, but have not synced all of the -* old dirty pages. -*/ - done =1 ; -break ; - } +/* +* We stop writing back only if we are not doing +* integrity sync. In case of integrity sync we have to +* keep going until we have written all the pages +* we tagged for writeback prior to entering this loop. +*/ +if (--wbc->nr_to_write <=0 && + wbc->sync_mode ==WB_SYNC_NONE ) { + done =1 ; +break ; } }pagevec_release (&pvec);Signature · 7 lines
1.7.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs
Looks good,
_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs