On Tue, Oct 11, 2011 at 07:30:07AM +0800, Jan Kara wrote: > On Mon 10-10-11 19:31:30, Wu Fengguang wrote: > > On Mon, Oct 10, 2011 at 07:21:33PM +0800, Jan Kara wrote: > > > Hi Fengguang, > > > > > > On Sat 08-10-11 12:00:36, Wu Fengguang wrote: > > > > The test results look not good: btrfs is heavily impacted and the > > > > other filesystems are slightly impacted. > > > > > > > > I'll send you the detailed logs in private emails (too large for the > > > > mailing list). Basically I noticed many writeback_wait traces that never > > > > appear w/o this patch. > > > OK, thanks for running these tests. I'll have a look at detailed logs. > > > I guess the difference can be caused by changes in redirty/requeue logic in > > > the second patch (the changes in the first patch could possibly make > > > several writeback_wait events from one event but never could introduce new > > > events). > > > > > > I guess I'll also try to reproduce the problem since it should be pretty > > > easy when you see such a huge regression even with 1 dd process on btrfs > > > filesystem. > > > > > > > In the btrfs cases that see larger regressions, I see large fluctuations > > > > in the writeout bandwidth and long disk idle periods. It's still a bit > > > > puzzling how all these happen.. > > > Yes, I don't understand it yet either... > > > > Jan, it's obviously caused by this chunk, which is not really > > necessary for fixing Christoph's problem. So the easy way is to go > > ahead without this chunk. > Yes, thanks a lot for debugging this! I'd still like to understand why > the hunk below is causing such a big problem to btrfs. I was looking into > the traces and all I could find so far was that for some reason relevant > inode (ino 257) was not getting queued for writeback for a long time (e.g. > 20 seconds) which introduced disk idle times and thus bad throughput. But I > don't understand why the inode was not queue for such a long time yet... > Today it's too late but I'll continue with my investigation tomorrow. Yeah, I have exactly the same observation and puzzle.. > > The remaining problems is, the simple dd tests may not be the suitable > > workloads to demonstrate the patches' usefulness to XFS. > Maybe, hopefully Christoph will tell use whether patches work for him or > not. The explanation could be, there are ignorable differences between redirty_tail() and requeue_io() for XFS background writeback, because the background writeback simply ignores inode->dirtied_when. Thanks, Fengguang -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
