All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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.