From: David Chinner <dgc@sgi.com>
To: Chris Mason <chris.mason@oracle.com>
Cc: akpm@osdl.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] avoid too many boundaries in DIO
Date: Fri, 10 Nov 2006 17:35:46 +1100 [thread overview]
Message-ID: <20061110063546.GF11034@melbourne.sgi.com> (raw)
In-Reply-To: <20061110014854.GS10889@think.oraclecorp.com>
On Thu, Nov 09, 2006 at 08:48:54PM -0500, Chris Mason wrote:
> Dave Chinner found a 10% performance regression with ext3 when using DIO
> to fill holes instead of buffered IO. On large IOs, the ext3 get_block
> routine will send more than a page worth of blocks back to DIO via a
> single buffer_head with a large b_size value.
>
> The DIO code iterates through this massive block and tests for a
> boundary buffer over and over again. For every block size unit spanned
> by the big map_bh, the boundary bit is tested and a bio may be forced
> down to the block layer.
>
> There are two potential fixes, one is to ignore the boundary bit on
> large regions returned by the FS. DIO can't tell which part of the big
> region was a boundary, and so it may not be a good idea to trust the
> hint.
>
> This patch just clears the boundary bit after using it once. It is 10%
> faster for a streaming DIO write w/blocksize of 512k on my sata drive.
8p altix, 8GB RAM, 64 FC disks, >2.5GiB/s sustainable raw throughput.
dm stripe, outer 1GB of each disk for 64GB volume. Chunk size 128k.
Single thread Direct I/O, I/O size of 512MiB, sequential file extend.
# mkfs.ext3 -E stride-size=32 /dev/mapper/testvol
# mkfs.xfs -f -d sunit=256,swidth=16384 /dev/mapper/testvol
ext3 mounted data=ordered; data=writeback results are the same
for direct I/O.
2.6.19-rc3-pl is 2.6.19-rc3 + the direct I/o placeholder patches.
2.6.19-rc3-pl-bd is 2.6.19-rc3-pl plus the boundary patch.
Kernel fs throughput I/Os/s sys+intr
----------- ---- ---------- ------- ------
2.6.19-rc3 ext3 660MiB/s ~36,000 70+60
2.6.19-rc3-pl ext3 600MiB/s ~36,000 70+60
2.6.19-rc3-pl-bd ext3 715MiB/s ~16,000 45+35
2.6.19-rc3 xfs 2.28GiB/s ~18,000 65+65
2.6.19-rc3-pl xfs 2.24GiB/s ~18,000 65+65
2.6.19-rc3-pl-bd xfs 2.26GiB/s ~18,000 65+65
Hole filling with direct I/O shows equivalent results.
The boundary patch doubles the average I/O size of ext3 and
substantially reduces CPU usage for direct I/O. Nice one, Chris.
Cheers,
Dave.
--
Dave Chinner
Principal Engineer
SGI Australian Software Group
next prev parent reply other threads:[~2006-11-10 6:36 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-11-10 1:48 [PATCH] avoid too many boundaries in DIO Chris Mason
2006-11-10 6:35 ` David Chinner [this message]
2006-11-10 6:56 ` Andrew Morton
2006-11-10 21:49 ` Chris Mason
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20061110063546.GF11034@melbourne.sgi.com \
--to=dgc@sgi.com \
--cc=akpm@osdl.org \
--cc=chris.mason@oracle.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox