linux-kernel - Re: [RESEND] [PATCH] readahead:add blk_run_backing

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Mon, 3 Aug 2009 13:44:28 +0200
From:	Ronald Moesbergen <intercommit@...il.com>
To:	Vladislav Bolkhovitin <vst@...b.net>
Cc:	fengguang.wu@...el.com, linux-kernel@...r.kernel.org,
	akpm@...ux-foundation.org, kosaki.motohiro@...fujitsu.com,
	Alan.Brunelle@...com, linux-fsdevel@...r.kernel.org,
	jens.axboe@...cle.com, randy.dunlap@...cle.com,
	Bart Van Assche <bart.vanassche@...il.com>
Subject: Re: [RESEND] [PATCH] readahead:add blk_run_backing_dev

2009/8/3 Vladislav Bolkhovitin <vst@...b.net>:
> Ronald Moesbergen, on 08/03/2009 01:15 PM wrote:
>>
>> 2009/7/31 Vladislav Bolkhovitin <vst@...b.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-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/