linux-kernel - Re: [RESEND][PATCH v2] block: remove plugging at buffered write time

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20120413014026.GA9027@localhost>
Date:	Fri, 13 Apr 2012 09:40:26 +0800
From:	Fengguang Wu <fengguang.wu@...el.com>
To:	Jan Kara <jack@...e.cz>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Jeff Moyer <jmoyer@...hat.com>, Jens Axboe <axboe@...nel.dk>,
	linux-fsdevel@...r.kernel.org, LKML <linux-kernel@...r.kernel.org>,
	Dave Chinner <david@...morbit.com>,
	Christoph Hellwig <hch@...radead.org>,
	Chris Mason <chris.mason@...cle.com>,
	Shaohua Li <shli@...ionio.com>
Subject: Re: [RESEND][PATCH v2] block: remove plugging at buffered write time

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/