From: Suparna Bhattacharya <suparna@in.ibm.com>
To: Andrew Morton <akpm@osdl.org>
Cc: Badari Pulavarty <pbadari@us.ibm.com>,
sct@redhat.com, ext4 <linux-ext4@vger.kernel.org>
Subject: Re: ext3 sequential read performance (~20%) degrade
Date: Fri, 15 Sep 2006 11:20:05 +0530 [thread overview]
Message-ID: <20060915055005.GA12172@in.ibm.com> (raw)
In-Reply-To: <20060914170308.9595141c.akpm@osdl.org>
On Thu, Sep 14, 2006 at 05:03:08PM -0700, Andrew Morton wrote:
> On Thu, 14 Sep 2006 16:36:12 -0700
> Badari Pulavarty <pbadari@us.ibm.com> wrote:
>
> > Hi Andrew,
> >
> > I have been working on tracking down ~20% performance degrade for
> > sequential read performance for ext3.
>
> oop. I'd kinda prefer that we discover things like this before the patch
> gets into mainline.
>
> > Finally narrowed it down to get_blocks() support. If I force
> > ext3_get_blocks_handle() to always return 1 block - I get better
> > IO rate. I did all the usual stuff, tracked down requests, traced
> > blocksizes, looked at readahead code, looked at mpage_readpages()
> > etc.. I still can't figure out how to explain the degrade..
> >
> > Any suggestions on how to track it down.
>
> Learn to driver Jens's blktrace stuff, find out why the IO scheduling went
> bad.
>
> Number one suspicion: the buffer_boundary() stuff isn't working.
I think you are right about that - perhaps something along
the lines of the following patch (untested) would help ?
If this is the problem then I guess the degradation should show up for DIO
as well.
-----------------------------
The boundary block check in ext3_get_blocks_handle needs to be adjusted
against the count of blocks mapped in this call, now that it can map
more than one block.
linux-2.6.18-rc5-suparna/fs/ext3/inode.c | 2 +-
1 files changed, 1 insertion(+), 1 deletion(-)
diff -puN fs/ext3/inode.c~ext3-multiblock-boundary-fix fs/ext3/inode.c
--- linux-2.6.18-rc5/fs/ext3/inode.c~ext3-multiblock-boundary-fix 2006-09-15 10:53:12.000000000 +0530
+++ linux-2.6.18-rc5-suparna/fs/ext3/inode.c 2006-09-15 10:54:30.000000000 +0530
@@ -925,7 +925,7 @@ int ext3_get_blocks_handle(handle_t *han
set_buffer_new(bh_result);
got_it:
map_bh(bh_result, inode->i_sb, le32_to_cpu(chain[depth-1].key));
- if (blocks_to_boundary == 0)
+ if (count > blocks_to_boundary)
set_buffer_boundary(bh_result);
err = count;
/* Clean up and exit */
_
Regards
Suparna
--
Suparna Bhattacharya (suparna@in.ibm.com)
Linux Technology Center
IBM Software Lab, India
next prev parent reply other threads:[~2006-09-15 5:48 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-09-14 23:36 ext3 sequential read performance (~20%) degrade Badari Pulavarty
2006-09-15 0:03 ` Andrew Morton
2006-09-15 5:50 ` Suparna Bhattacharya [this message]
2006-09-15 16:01 ` Badari Pulavarty
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=20060915055005.GA12172@in.ibm.com \
--to=suparna@in.ibm.com \
--cc=akpm@osdl.org \
--cc=linux-ext4@vger.kernel.org \
--cc=pbadari@us.ibm.com \
--cc=sct@redhat.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.