From mboxrd@z Thu Jan 1 00:00:00 1970 From: Fengguang Wu Subject: Re: [RESEND][PATCH v2] block: remove plugging at buffered write time Date: Fri, 13 Apr 2012 09:40:26 +0800 Message-ID: <20120413014026.GA9027@localhost> References: <20120408010600.GA31377@localhost> <20120411161344.309f12ef.akpm@linux-foundation.org> <20120412013224.GA5859@localhost> <20120412022040.GA6800@localhost> <20120412142634.GA16559@quack.suse.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Andrew Morton , Jeff Moyer , Jens Axboe , linux-fsdevel@vger.kernel.org, LKML , Dave Chinner , Christoph Hellwig , Chris Mason , Shaohua Li To: Jan Kara Return-path: Content-Disposition: inline In-Reply-To: <20120412142634.GA16559@quack.suse.cz> Sender: linux-kernel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Thu, Apr 12, 2012 at 04:26:34PM +0200, Jan Kara wrote: > Hi Fengguang, > > On Thu 12-04-12 10:20:40, Wu Fengguang wrote: > > > > > > Note that plugging for O_SYNC writes is also removed. The user may pass > > > > > > arbitrary @size arguments, which may be much larger than the preferable > > > > > > I/O size, or may cross extent/device boundaries. Let the lower layers > > > > > > handle the plugging. Otherwise the plugging code here will turn the > > > > > > low level plugging into no-ops. > > > > > > > > > > I assume you have some numbers to back this up, right? Care to share > > > > > those? > > > > > > > > Yes please. > > > > > > > > We've broken this stuff a few times recently - we should review and > > > > test carefully. > > > > > > Yes sure. Last time I posted the patch, I did some tests and found no > > > performance changes. Now for 3.3, the tests started days ago have not > > > finished now (partly because it is stalled for quite long time due to > > > unknown reason). The now-available numbers for bs=4k dd's look fine. > > > The pending tests are for bs=1M dd's and some random fio workloads. > > > > > > > The changes are basically small enough to be considered noises. > > But anyway here are some interpretations: > > > > - application visible data write performance (write_bw) is almost the same > > - it slightly reduces the real IOs that hit disk (io_wkB_s, io_rkB_s) > > - disk utilization slightly increased > > - CPU time is slightly reduced > > > Well, two of the throughput numbers stand out (in both directions > actually) although they seem to be more extreme configurations so maybe it > is a noise. But maybe it would deserve further check: > > > $ ./compare-io bay/*/*-{3.3.0,3.3.0-plug+} > > 3.3.0 3.3.0-plug+ > > ------------------------ ------------------------ > ... > > 2.60 +7.1% 2.78 bay/thresh=1M/btrfs-10dd-1-3.3.0 > > 3.72 -12.5% 3.25 bay/thresh=1M/btrfs-1dd-1-3.3.0 > ... Yeah. In fact I noticed btrfs performing badly on the 1MB dirty threshold cases comparing to other filesystems. thresh=10MB cases are fine. It looks better to explore this first. My hunch is that fixing this issue may also change its sensitiveness to the plugging. 3.3.0 3.3.0-plug+ ------------------------ ------------------------ 2.60 +7.1% 2.78 bay/thresh=1M/btrfs-10dd-1-3.3.0 3.72 -12.5% 3.25 bay/thresh=1M/btrfs-1dd-1-3.3.0 62.41 +0.3% 62.60 bay/thresh=1M/ext3-10dd-1-3.3.0 58.61 +0.4% 58.82 bay/thresh=1M/ext3-1dd-1-3.3.0 70.70 -1.1% 69.92 bay/thresh=1M/ext4-10dd-1-3.3.0 84.81 +0.1% 84.90 bay/thresh=1M/ext4-1dd-1-3.3.0 66.05 -0.1% 65.97 bay/thresh=1M/xfs-10dd-1-3.3.0 74.81 +0.1% 74.85 bay/thresh=1M/xfs-1dd-1-3.3.0 > I looked at other iostat numbers as well, but seeing quite some changes > in both directions I'd say that those iostat numbers are too noisy to draw > serious conclusion from them. Agreed. Thanks, Fengguang