From: Tomasz Chmielewski <mangoo@wpkg.org>
Cc: linux-kernel@vger.kernel.org, linux-raid@vger.kernel.org,
rshitrit@marvell.com, dan.j.williams@intel.com,
nickpiggin@yahoo.com.au, Justin Piszcz <jpiszcz@lucidpixels.com>,
ilmari@ilmari.org
Subject: Re: [PATCH 00/16] raid acceleration and asynchronous offload api for 2.6.22
Date: Thu, 10 May 2007 17:32:03 +0200 [thread overview]
Message-ID: <46433AF3.1040707@wpkg.org> (raw)
In-Reply-To: <4643283B.2060203@wpkg.org>
Tomasz Chmielewski schrieb:
> Ronen Shitrit wrote:
>
>> The resync numbers you sent, looks very promising :)
>> Do you have any performance numbers that you can share for these set of
>> patches, which shows the Rd/Wr IO bandwidth.
>
> I have some simple tests made with hdparm, with the results I don't
> understand.
>
> We see hdparm results are fine if we access the whole device:
>
> thecus:~# hdparm -Tt /dev/sdd
>
> /dev/sdd:
> Timing cached reads: 392 MB in 2.00 seconds = 195.71 MB/sec
> Timing buffered disk reads: 146 MB in 3.01 seconds = 48.47 MB/sec
>
>
> But are 10 times worse (Timing buffered disk reads) when we access
> partitions:
There seems to be another side effect when comparing DMA engine in
2.6.17-iop1 to 2.6.21-iop1: network performance.
For simple network tests, I use "netperf" tool to measure network
performance.
With 2.6.17-iop1 and all DMA offloading options enabled (selectable in
System type ---> IOP3xx Implementation Options --->), I get nearly 25
MB/s throughput.
With 2.6.21-iop1 and all DMA offloading optons enabled (moved to Device
Drivers ---> DMA Engine support --->), I get only about 10 MB/s
throughput.
Additionally, on 2.6.21-iop1, I get lots of "dma_cookie < 0" printed by
the kernel.
--
Tomasz Chmielewski
http://wpkg.org
WARNING: multiple messages have this Message-ID (diff)
From: Tomasz Chmielewski <mangoo@wpkg.org>
To: unlisted-recipients:; (no To-header on input)
Cc: linux-kernel@vger.kernel.org, linux-raid@vger.kernel.org,
rshitrit@marvell.com, dan.j.williams@intel.com,
nickpiggin@yahoo.com.au, Justin Piszcz <jpiszcz@lucidpixels.com>,
ilmari@ilmari.org
Subject: Re: [PATCH 00/16] raid acceleration and asynchronous offload api for 2.6.22
Date: Thu, 10 May 2007 17:32:03 +0200 [thread overview]
Message-ID: <46433AF3.1040707@wpkg.org> (raw)
In-Reply-To: <4643283B.2060203@wpkg.org>
Tomasz Chmielewski schrieb:
> Ronen Shitrit wrote:
>
>> The resync numbers you sent, looks very promising :)
>> Do you have any performance numbers that you can share for these set of
>> patches, which shows the Rd/Wr IO bandwidth.
>
> I have some simple tests made with hdparm, with the results I don't
> understand.
>
> We see hdparm results are fine if we access the whole device:
>
> thecus:~# hdparm -Tt /dev/sdd
>
> /dev/sdd:
> Timing cached reads: 392 MB in 2.00 seconds = 195.71 MB/sec
> Timing buffered disk reads: 146 MB in 3.01 seconds = 48.47 MB/sec
>
>
> But are 10 times worse (Timing buffered disk reads) when we access
> partitions:
There seems to be another side effect when comparing DMA engine in
2.6.17-iop1 to 2.6.21-iop1: network performance.
For simple network tests, I use "netperf" tool to measure network
performance.
With 2.6.17-iop1 and all DMA offloading options enabled (selectable in
System type ---> IOP3xx Implementation Options --->), I get nearly 25
MB/s throughput.
With 2.6.21-iop1 and all DMA offloading optons enabled (moved to Device
Drivers ---> DMA Engine support --->), I get only about 10 MB/s
throughput.
Additionally, on 2.6.21-iop1, I get lots of "dma_cookie < 0" printed by
the kernel.
--
Tomasz Chmielewski
http://wpkg.org
next prev parent reply other threads:[~2007-05-10 15:32 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-05-10 14:12 [PATCH 00/16] raid acceleration and asynchronous offload api for 2.6.22 Tomasz Chmielewski
2007-05-10 15:32 ` Tomasz Chmielewski [this message]
2007-05-10 15:32 ` Tomasz Chmielewski
-- strict thread matches above, loose matches on Subject: below --
2007-05-09 12:46 Ronen Shitrit
2007-05-02 6:14 Dan Williams
2007-05-02 6:55 ` Nick Piggin
2007-05-02 15:45 ` Williams, Dan J
2007-05-02 15:45 ` Williams, Dan J
2007-05-02 15:55 ` Justin Piszcz
2007-05-02 16:17 ` Williams, Dan J
2007-05-02 16:17 ` Williams, Dan J
2007-05-02 16:19 ` Justin Piszcz
2007-05-02 16:36 ` Dagfinn Ilmari Mannsåker
2007-05-02 16:36 ` Dagfinn Ilmari Mannsåker
2007-05-02 16:42 ` Williams, Dan J
2007-05-02 16:42 ` Williams, Dan J
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=46433AF3.1040707@wpkg.org \
--to=mangoo@wpkg.org \
--cc=dan.j.williams@intel.com \
--cc=ilmari@ilmari.org \
--cc=jpiszcz@lucidpixels.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-raid@vger.kernel.org \
--cc=nickpiggin@yahoo.com.au \
--cc=rshitrit@marvell.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.