From: Chris Mason <chris.mason@oracle.com>
To: akpm@osdl.org, linux-kernel@vger.kernel.org
Cc: dgc@sgi.com
Subject: [PATCH] avoid too many boundaries in DIO
Date: Thu, 9 Nov 2006 20:48:54 -0500 [thread overview]
Message-ID: <20061110014854.GS10889@think.oraclecorp.com> (raw)
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.
Signed-off-by: Chris Mason <chris.mason@oracle.com>
diff -r 38d08cbe880b fs/direct-io.c
--- a/fs/direct-io.c Thu Nov 09 20:02:08 2006 -0500
+++ b/fs/direct-io.c Thu Nov 09 20:31:12 2006 -0500
@@ -959,6 +959,17 @@ do_holes:
BUG_ON(this_chunk_bytes == 0);
dio->boundary = buffer_boundary(map_bh);
+
+ /*
+ * get_block may return more than one page worth
+ * of blocks. Only make the first one a boundary.
+ * This is still sub-optimal, it probably only
+ * makes sense to play with boundaries when
+ * get_block returns a single FS block sized
+ * unit.
+ */
+ clear_buffer_boundary(map_bh);
+
ret = submit_page_section(dio, page, offset_in_page,
this_chunk_bytes, dio->next_block_for_io);
if (ret) {
next reply other threads:[~2006-11-10 1:48 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-11-10 1:48 Chris Mason [this message]
2006-11-10 6:35 ` [PATCH] avoid too many boundaries in DIO David Chinner
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=20061110014854.GS10889@think.oraclecorp.com \
--to=chris.mason@oracle.com \
--cc=akpm@osdl.org \
--cc=dgc@sgi.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