From mboxrd@z Thu Jan 1 00:00:00 1970 From: Wu Fengguang Subject: Re: [PATCH 2/2] writeback: Replace some redirty_tail() calls with requeue_io() Date: Tue, 11 Oct 2011 10:36:38 +0800 Message-ID: <20111011023638.GA20162@localhost> References: <20110918140737.GA15366@localhost> <20111005173908.GF23467@quack.suse.cz> <20111007134347.GA6891@localhost> <20111007142201.GB30754@quack.suse.cz> <20111007142928.GA14427@localhost> <20111007144504.GC30754@quack.suse.cz> <20111008040036.GA30069@localhost> <20111010112133.GA3944@quack.suse.cz> <20111010113130.GA6879@localhost> <20111010233007.GN3944@quack.suse.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "linux-fsdevel@vger.kernel.org" , Dave Chinner , Christoph Hellwig , Chris Mason To: Jan Kara Return-path: Received: from mga03.intel.com ([143.182.124.21]:37640 "EHLO mga03.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753108Ab1JKCgm (ORCPT ); Mon, 10 Oct 2011 22:36:42 -0400 Content-Disposition: inline In-Reply-To: <20111010233007.GN3944@quack.suse.cz> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: 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