From: Ronald Moesbergen <intercommit@gmail.com>
To: Vladislav Bolkhovitin <vst@vlnb.net>
Cc: fengguang.wu@intel.com, linux-kernel@vger.kernel.org,
akpm@linux-foundation.org, kosaki.motohiro@jp.fujitsu.com,
Alan.Brunelle@hp.com, linux-fsdevel@vger.kernel.org,
jens.axboe@oracle.com, randy.dunlap@oracle.com,
Bart Van Assche <bart.vanassche@gmail.com>
Subject: Re: [RESEND] [PATCH] readahead:add blk_run_backing_dev
Date: Mon, 3 Aug 2009 13:44:28 +0200 [thread overview]
Message-ID: <a0272b440908030444g4808ddf4o35eb587b91717cb4@mail.gmail.com> (raw)
In-Reply-To: <4A76ABD5.9020808@vlnb.net>
2009/8/3 Vladislav Bolkhovitin <vst@vlnb.net>:
> Ronald Moesbergen, on 08/03/2009 01:15 PM wrote:
>>
>> 2009/7/31 Vladislav Bolkhovitin <vst@vlnb.net>:
>>>
>>> OK, as I expected, on the SCST level everything is clear and the forced
>>> ordering change didn't change anything.
>>>
>>> But still, a single read stream must be the fastest from single thread.
>>> Otherwise, there's something wrong somewhere in the I/O path: block
>>> layer,
>>> RA, I/O scheduler. And, apparently, this is what we have and should find
>>> out
>>> the cause.
>>>
>>> Can you check if noop on the target and/or initiator makes any
>>> difference?
>>> Case 5 with 1 and 2 threads will be sufficient.
>>
>> That doesn't seem to help:
>>
>> client kernel: 2.6.26-15lenny3 (debian)
>> server kernel: 2.6.29.5 with readahead-context, blk_run_backing_dev
>> and io_context, forced_order
>>
>> With one IO thread:
>> 5) client: default, server: default (server noop, client noop)
>> blocksize R R R R(avg, R(std R
>> (bytes) (s) (s) (s) MB/s) ,MB/s) (IOPS)
>> 67108864 17.612 21.113 21.355 51.532 4.680 0.805
>> 33554432 18.329 18.523 19.049 54.969 0.891 1.718
>> 16777216 18.497 18.219 17.042 57.217 2.059 3.576
>>
>> With two threads:
>> 5) client: default, server: default (server noop, client noop)
>> blocksize R R R R(avg, R(std R
>> (bytes) (s) (s) (s) MB/s) ,MB/s) (IOPS)
>> 67108864 17.436 18.376 20.493 54.807 3.634 0.856
>> 33554432 17.466 16.980 18.261 58.337 1.740 1.823
>> 16777216 18.222 17.567 18.077 57.045 0.901 3.565
>
> And with client cfq, server noop?
client kernel: 2.6.26-15lenny3 (debian)
server kernel: 2.6.29.5 with readahead-context, blk_run_backing_dev
and io_context, forced_order
With one IO thread:
5) client: default, server: default (server noop, client cfq)
blocksize R R R R(avg, R(std R
(bytes) (s) (s) (s) MB/s) ,MB/s) (IOPS)
67108864 16.019 16.434 15.730 63.777 1.144 0.997
33554432 16.020 16.624 15.936 63.258 1.183 1.977
16777216 15.966 15.465 16.115 64.630 1.145 4.039
With two threads:
5) client: default, server: default (server noop, client cfq)
blocksize R R R R(avg, R(std R
(bytes) (s) (s) (s) MB/s) ,MB/s) (IOPS)
67108864 16.504 15.762 14.842 65.335 2.848 1.021
33554432 16.080 16.627 15.766 63.406 1.386 1.981
16777216 15.489 16.627 16.043 63.842 1.846 3.990
Ronald.
WARNING: multiple messages have this Message-ID (diff)
From: Ronald Moesbergen <intercommit@gmail.com>
To: Vladislav Bolkhovitin <vst@vlnb.net>
Cc: fengguang.wu@intel.com, linux-kernel@vger.kernel.org,
akpm@linux-foundation.org, kosaki.motohiro@jp.fujitsu.com,
Alan.Brunelle@hp.com, linux-fsdevel@vger.kernel.org,
jens.axboe@oracle.com, randy.dunlap@oracle.com,
Bart Van Assche <bart.vanassche@gmail.com>
Subject: Re: [RESEND] [PATCH] readahead:add blk_run_backing_dev
Date: Mon, 3 Aug 2009 13:44:28 +0200 [thread overview]
Message-ID: <a0272b440908030444g4808ddf4o35eb587b91717cb4@mail.gmail.com> (raw)
In-Reply-To: <4A76ABD5.9020808@vlnb.net>
2009/8/3 Vladislav Bolkhovitin <vst@vlnb.net>:
> Ronald Moesbergen, on 08/03/2009 01:15 PM wrote:
>>
>> 2009/7/31 Vladislav Bolkhovitin <vst@vlnb.net>:
>>>
>>> OK, as I expected, on the SCST level everything is clear and the forced
>>> ordering change didn't change anything.
>>>
>>> But still, a single read stream must be the fastest from single thread.
>>> Otherwise, there's something wrong somewhere in the I/O path: block
>>> layer,
>>> RA, I/O scheduler. And, apparently, this is what we have and should find
>>> out
>>> the cause.
>>>
>>> Can you check if noop on the target and/or initiator makes any
>>> difference?
>>> Case 5 with 1 and 2 threads will be sufficient.
>>
>> That doesn't seem to help:
>>
>> client kernel: 2.6.26-15lenny3 (debian)
>> server kernel: 2.6.29.5 with readahead-context, blk_run_backing_dev
>> and io_context, forced_order
>>
>> With one IO thread:
>> 5) client: default, server: default (server noop, client noop)
>> blocksize R R R R(avg, R(std R
>> (bytes) (s) (s) (s) MB/s) ,MB/s) (IOPS)
>> 67108864 17.612 21.113 21.355 51.532 4.680 0.805
>> 33554432 18.329 18.523 19.049 54.969 0.891 1.718
>> 16777216 18.497 18.219 17.042 57.217 2.059 3.576
>>
>> With two threads:
>> 5) client: default, server: default (server noop, client noop)
>> blocksize R R R R(avg, R(std R
>> (bytes) (s) (s) (s) MB/s) ,MB/s) (IOPS)
>> 67108864 17.436 18.376 20.493 54.807 3.634 0.856
>> 33554432 17.466 16.980 18.261 58.337 1.740 1.823
>> 16777216 18.222 17.567 18.077 57.045 0.901 3.565
>
> And with client cfq, server noop?
client kernel: 2.6.26-15lenny3 (debian)
server kernel: 2.6.29.5 with readahead-context, blk_run_backing_dev
and io_context, forced_order
With one IO thread:
5) client: default, server: default (server noop, client cfq)
blocksize R R R R(avg, R(std R
(bytes) (s) (s) (s) MB/s) ,MB/s) (IOPS)
67108864 16.019 16.434 15.730 63.777 1.144 0.997
33554432 16.020 16.624 15.936 63.258 1.183 1.977
16777216 15.966 15.465 16.115 64.630 1.145 4.039
With two threads:
5) client: default, server: default (server noop, client cfq)
blocksize R R R R(avg, R(std R
(bytes) (s) (s) (s) MB/s) ,MB/s) (IOPS)
67108864 16.504 15.762 14.842 65.335 2.848 1.021
33554432 16.080 16.627 15.766 63.406 1.386 1.981
16777216 15.489 16.627 16.043 63.842 1.846 3.990
Ronald.
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2009-08-03 11:44 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
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 [this message]
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=a0272b440908030444g4808ddf4o35eb587b91717cb4@mail.gmail.com \
--to=intercommit@gmail.com \
--cc=Alan.Brunelle@hp.com \
--cc=akpm@linux-foundation.org \
--cc=bart.vanassche@gmail.com \
--cc=fengguang.wu@intel.com \
--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 \
--cc=vst@vlnb.net \
/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.