From: Wu Fengguang <fengguang.wu@intel.com>
To: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Cc: "Alan D. Brunelle" <Alan.Brunelle@hp.com>,
Hisashi Hifumi <hifumi.hisashi@oss.ntt.co.jp>,
Andrew Morton <akpm@linux-foundation.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
Jens Axboe <jens.axboe@oracle.com>,
Randy Dunlap <randy.dunlap@oracle.com>
Subject: Re: [RESEND] [PATCH] readahead:add blk_run_backing_dev
Date: Sun, 7 Jun 2009 06:45:38 +0800 [thread overview]
Message-ID: <20090606224538.GA6173@localhost> (raw)
In-Reply-To: <20090606233056.7B9F.A69D9226@jp.fujitsu.com>
On Sat, Jun 06, 2009 at 10:36:41PM +0800, KOSAKI Motohiro wrote:
>
> sorry for late responce.
> I wonder why I and Wu don't contain Cc list in this thread.
[restore more CC]
> > Hisashi Hifumi wrote:
> > > At 09:36 09/06/01, Andrew Morton wrote:
> > >> On Fri, 29 May 2009 14:35:55 +0900 Hisashi Hifumi
> > >> <hifumi.hisashi@oss.ntt.co.jp> wrote:
> > >>
> > >>> I added blk_run_backing_dev on page_cache_async_readahead
> > >>> so readahead I/O is unpluged to improve throughput on
> > >>> especially RAID environment.
> > >> I skipped the last version of this because KOSAKI Motohiro
> > >> <kosaki.motohiro@jp.fujitsu.com> said "Please attach blktrace analysis ;)".
> > >>
> > >> I'm not sure why he asked for that, but he's a smart chap and
> > >> presumably had his reasons.
> > >>
> > >> If you think that such an analysis is unneeded, or isn't worth the time
> > >> to generate then please tell us that. But please don't just ignore the
> > >> request!
> > >
> > > Hi Andrew.
> > >
> > > Sorry for this.
> > >
> > > I did not ignore KOSAKI Motohiro's request.
> > > I've got blktrace output for both with and without the patch,
> > > but I just did not clarify the reason for throuput improvement
> > > from this result.
> > >
> > > I do not notice any difference except around unplug behavior by dd.
> > > Comments?
> >
> > Pardon my ignorance on the global issues concerning the patch, but
> > specifically looking at the traces generated by blktrace leads one to
> > also note that the patched version may generate inefficiencies in other
> > places in the kernel by reducing the merging going on. In the unpatched
> > version it looks like (generally) that two incoming bio's are able to be
> > merged to generate a single I/O request. In the patched version -
> > because of the quicker unplug(?) - no such merging is going on. This
> > leads to more work lower in the stack (twice as many I/O operations
> > being managed), perhaps increased interrupts & handling &c. [This may be
> > acceptable if the goal is to decrease latencies on a per-bio basis...]
> >
> > Do you have a place where the raw blktrace data can be retrieved for
> > more in-depth analysis?
>
> I think your comment is really adequate. In another thread, Wu Fengguang pointed
> out the same issue.
> I and Wu also wait his analysis.
And do it with a large readahead size :)
Alan, this was my analysis:
: Hifumi, can you help retest with some large readahead size?
:
: Your readahead size (128K) is smaller than your max_sectors_kb (256K),
: so two readahead IO requests get merged into one real IO, that means
: half of the readahead requests are delayed.
ie. two readahead requests get merged and complete together, thus the effective
IO size is doubled but at the same time it becomes completely synchronous IO.
:
: The IO completion size goes down from 512 to 256 sectors:
:
: before patch:
: 8,0 3 177955 50.050313976 0 C R 8724991 + 512 [0]
: 8,0 3 177966 50.053380250 0 C R 8725503 + 512 [0]
: 8,0 3 177977 50.056970395 0 C R 8726015 + 512 [0]
: 8,0 3 177988 50.060326743 0 C R 8726527 + 512 [0]
: 8,0 3 177999 50.063922341 0 C R 8727039 + 512 [0]
:
: after patch:
: 8,0 3 257297 50.000760847 0 C R 9480703 + 256 [0]
: 8,0 3 257306 50.003034240 0 C R 9480959 + 256 [0]
: 8,0 3 257307 50.003076338 0 C R 9481215 + 256 [0]
: 8,0 3 257323 50.004774693 0 C R 9481471 + 256 [0]
: 8,0 3 257332 50.006865854 0 C R 9481727 + 256 [0]
Thanks,
Fengguang
next prev parent reply other threads:[~2009-06-06 22:45 UTC|newest]
Thread overview: 81+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-05-29 5:35 [RESEND] [PATCH] readahead:add blk_run_backing_dev Hisashi Hifumi
2009-06-01 0:36 ` Andrew Morton
2009-06-01 1:04 ` Hisashi Hifumi
2009-06-05 15:15 ` Alan D. Brunelle
2009-06-06 14:36 ` KOSAKI Motohiro
2009-06-06 22:45 ` Wu Fengguang [this message]
2009-06-18 19:04 ` Andrew Morton
2009-06-20 3:55 ` Wu Fengguang
2009-06-20 12:29 ` Vladislav Bolkhovitin
2009-06-29 9:34 ` Wu Fengguang
2009-06-29 10:26 ` Ronald Moesbergen
2009-06-29 10:26 ` Ronald Moesbergen
2009-06-29 10:55 ` Vladislav Bolkhovitin
2009-06-29 12:54 ` Wu Fengguang
2009-06-29 12:58 ` Bart Van Assche
2009-06-29 13:01 ` Wu Fengguang
2009-06-29 13:04 ` Vladislav Bolkhovitin
2009-06-29 13:13 ` Wu Fengguang
2009-06-29 13:28 ` Wu Fengguang
2009-06-29 14:43 ` Ronald Moesbergen
2009-06-29 14:51 ` Wu Fengguang
2009-06-29 14:56 ` Ronald Moesbergen
2009-06-29 15:37 ` Vladislav Bolkhovitin
2009-06-29 14:00 ` Ronald Moesbergen
2009-06-29 14:21 ` Wu Fengguang
2009-06-29 15:01 ` Wu Fengguang
2009-06-29 15:37 ` Vladislav Bolkhovitin
[not found] ` <20090630010414.GB31418@localhost>
2009-06-30 10:54 ` Vladislav Bolkhovitin
2009-07-01 13:07 ` Ronald Moesbergen
2009-07-01 18:12 ` Vladislav Bolkhovitin
2009-07-03 9:14 ` Ronald Moesbergen
2009-07-03 10:56 ` Vladislav Bolkhovitin
2009-07-03 12:41 ` Ronald Moesbergen
2009-07-03 12:46 ` Vladislav Bolkhovitin
2009-07-04 15:19 ` Ronald Moesbergen
2009-07-06 11:12 ` Vladislav Bolkhovitin
2009-07-06 14:37 ` Ronald Moesbergen
2009-07-06 14:37 ` Ronald Moesbergen
2009-07-06 17:48 ` Vladislav Bolkhovitin
2009-07-07 6:49 ` Ronald Moesbergen
2009-07-07 6:49 ` Ronald Moesbergen
[not found] ` <4A5395FD.2040507@vlnb.net>
[not found] ` <a0272b440907080149j3eeeb9bat13f942520db059a8@mail.gmail.com>
2009-07-08 12:40 ` Vladislav Bolkhovitin
2009-07-10 6:32 ` Ronald Moesbergen
2009-07-10 8:43 ` Vladislav Bolkhovitin
2009-07-10 9:27 ` Vladislav Bolkhovitin
2009-07-13 12:12 ` Ronald Moesbergen
2009-07-13 12:36 ` Wu Fengguang
2009-07-13 12:47 ` Ronald Moesbergen
2009-07-13 12:52 ` Wu Fengguang
2009-07-14 18:52 ` Vladislav Bolkhovitin
2009-07-15 7:06 ` Wu Fengguang
2009-07-14 18:52 ` Vladislav Bolkhovitin
2009-07-15 6:30 ` Vladislav Bolkhovitin
2009-07-16 7:32 ` Ronald Moesbergen
2009-07-16 10:36 ` Vladislav Bolkhovitin
2009-07-16 14:54 ` Ronald Moesbergen
2009-07-16 16:03 ` Vladislav Bolkhovitin
2009-07-17 14:15 ` Ronald Moesbergen
2009-07-17 18:23 ` Vladislav Bolkhovitin
2009-07-20 7:20 ` Vladislav Bolkhovitin
2009-07-22 8:44 ` Ronald Moesbergen
2009-07-27 13:11 ` Vladislav Bolkhovitin
2009-07-28 9:51 ` Ronald Moesbergen
2009-07-28 19:07 ` Vladislav Bolkhovitin
2009-07-29 12:48 ` Ronald Moesbergen
2009-07-31 18:32 ` Vladislav Bolkhovitin
2009-08-03 9:15 ` Ronald Moesbergen
2009-08-03 9:20 ` Vladislav Bolkhovitin
2009-08-03 11:44 ` Ronald Moesbergen
2009-08-03 11:44 ` Ronald Moesbergen
2009-07-15 20:52 ` Kurt Garloff
2009-07-16 10:38 ` Vladislav Bolkhovitin
2009-06-30 10:22 ` Vladislav Bolkhovitin
2009-06-29 10:55 ` Vladislav Bolkhovitin
2009-06-29 13:00 ` Wu Fengguang
2009-09-22 20:58 ` Andrew Morton
2009-09-22 20:58 ` Andrew Morton
-- strict thread matches above, loose matches on Subject: below --
2009-09-23 1:48 Wu Fengguang
2009-09-23 1:48 ` [RESEND] [PATCH] readahead:add blk_run_backing_dev Wu Fengguang
2009-09-23 1:48 ` (unknown) Wu Fengguang
2009-05-22 0:09 [RESEND][PATCH] readahead:add blk_run_backing_dev Hisashi Hifumi
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=20090606224538.GA6173@localhost \
--to=fengguang.wu@intel.com \
--cc=Alan.Brunelle@hp.com \
--cc=akpm@linux-foundation.org \
--cc=hifumi.hisashi@oss.ntt.co.jp \
--cc=jens.axboe@oracle.com \
--cc=kosaki.motohiro@jp.fujitsu.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=randy.dunlap@oracle.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.