All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tomasz Chmielewski <mangoo@wpkg.org>
To: 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 16:12:11 +0200	[thread overview]
Message-ID: <4643283B.2060203@wpkg.org> (raw)

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:

thecus:/# hdparm -Tt /dev/sdc1 /dev/sdd1

/dev/sdc1:
  Timing cached reads:   396 MB in  2.01 seconds = 197.18 MB/sec
  Timing buffered disk reads:   16 MB in  3.32 seconds =   4.83 MB/sec

/dev/sdd1:
  Timing cached reads:   394 MB in  2.00 seconds = 196.89 MB/sec
  Timing buffered disk reads:   16 MB in  3.13 seconds =   5.11 MB/sec


Why is it so much worse?


I used 2.6.21-iop1 patches from http://sf.net/projects/xscaleiop; right 
now I use 2.6.17-iop1, for which the results are ~35 MB/s when accessing 
a device (/dev/sdd) or a partition (/dev/sdd1).


In kernel config, I enabled Intel DMA engines.

The device I use is Thecus n4100, it is "Platform: IQ31244 (XScale)", 
and has 600 MHz CPU.


-- 
Tomasz Chmielewski
http://wpkg.org

             reply	other threads:[~2007-05-10 14:12 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-05-10 14:12 Tomasz Chmielewski [this message]
2007-05-10 15:32 ` [PATCH 00/16] raid acceleration and asynchronous offload api for 2.6.22 Tomasz Chmielewski
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=4643283B.2060203@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.